Radical and compromise in the design of YUI3

Believe that every front-end engineers have their favorite JavaScript frame, said emotion or faith, JavaScript framework to bring people is not only convenient development, there is a pure logical beauty, whether it is the simplicity of jquery, or Yui magic like the sandbox, All make us have infinite imagination. However, the JS framework will not be able to do all the flawless, such as jquery in OO concessions, and Yui in the performance of the sacrifice, all to convey a flaw in the United States, an ideal of realism. Today, let's look at these sacrifices and concessions yui3 in the framework design so that we can have a deeper understanding of the full picture of Yui3 and make the best of its advantages.

1, one step of the seed in place or granular
The so-called seed one-step refers to a script tag that simply introduces a seed file into the page, such as prototype and jquery, As long as you introduce a prototype.js or jquery.js, they include each package of DOM operations and event into a single file and try to minimize it, the benefits are obvious, and the framework is simple to use. However Yui will these functions do a level division and granular design, abstract from the concept of "core", "Tools" and "components", each small function placed in a file, the need to go to their own reference, Yui documents given in a large number of demos are using this method, This design is clearly not as user-friendly as jquery, and not enough to use a fool, in order to achieve a small function, even to introduce three or four JS files. Yui do this for two reasons, one is Yui is too big, all the features into a file is indeed a bit unreliable, the second is for its dynamic loading of the framework design to do bedding.

2, manually introduce or dynamically load
The traditional way to write JS to the page is, directly to the JS file as a script tag path written in the page, the use of Yui can also introduce the page, but Yui more recommend the use of loader dynamic loading. The source of dynamic loading scripts is very complex, at present, the main reason is three, one, the page handwriting js tag will occupy an HTTP request, even if this request is a 304, dynamic loading of the file cache do not have to launch a real HTTP request, the second, dynamic loading can be implemented on-demand loading, And can be based on the JS file dependencies between the weight and sorting, handwriting tags loaded js files must allow developers to pay extra attention to the file sorting, duplication, etc., the third, dynamic loading is conducive to the semantics of the page code, which makes developers only care about "what is needed", and do not care about "how to get". When the project becomes bloated and the cost of maintenance becomes more and more high, this small and medium skill will be of great benefit.

3, a single entry or sandbox with logical start
We start a JS logic in the page is usually placed in a similar Ondomready method, if there are multiple logic in the page how to do? For example, a implements the logic a, the page code is like this

<script src= "Logica.js"/>
<script>
$.ondomready (function () {
___logica.start ();
});
</script>

This code is usually written at the end of the page where the HTML code accompanying the logic is buried somewhere in the page, and B to add logical b,b to the page is to first find the tail code and change it to look like this:

<script src= "Logica.js"/>
<script src= "Logicb.js"/>
<script>
$.ondomready (function () {
___logica.start ();
___logicb.start ();
});
</script>

Similarly, the HTML code that accompanies the B logic is buried somewhere in the page, in this way, JS logic and its accompanying HTML code so separated, so that the deletion of the function, often deleted HTML but forgot to delete js, or deleted JS forgot to remove HTML, in the reuse of code will also be a trouble. Similarly, when debugging, the engineer also opens two windows to focus on JS and HTML separately, even if the two pieces of code are in the same file. So it's better to write code like this:

HTML code snippet for <!–a logic –>
<script src= "Logica.js"/>
<script>
$.ondomready (function () {
___logica.start ();
});
</script>

...

HTML code snippet for <!–b logic –>
<script src= "Logicb.js"/>
<script>
$.ondomready (function () {
___logicb.start ();
});
</script>

This kind of coding writing is Yui advocated, is called the sandbox, each logic contained in a sandbox, each division of its mutual interference. When the third party to browse the code immediately understand that this is a separate function block, contains a typical HTML structure and startup logic of JS, to reuse, the whole piece of handcuffs go.

4, Code pollution or sandbox
Just mentioned that the sandbox can solve a part of the problem of code pollution, the new reading code no longer look at the garbled source, "look back" carefully looking for the corresponding relationship between HTML and JS. But this writing also has hidden dangers, now the front-end development more and more complex and more use of layering, such as the bottom of the use of Yui, the middle tier is a custom tool library, or add a Project Widget component library, write page logic is based on these libraries for development. In this case, each logic may be written in this way:

HTML code snippet for <!–a logic –>
Widget library for <script src= "Widget.js"/><!– Project –>
<script src= "Logica.js"/>
<script>
$.ondomready (function () {
___logica.start ();
});
</script>

Although we can agree that all the components used in the project are uniformly loaded into the page, but when the components are more and more, there is the contradiction between the one-step and the granulation, when each control occupies a single JS file and the accompanying CSS skin, A relatively complex logic becomes the manual introduction of JS files as described above, with the introduction of some obvious drawbacks:

<!– Complex A-logical HTML code snippets, using calendars, layers, slide –>,
<script src= calendar.js/><!– calendar –>
< Script src= "box.js"/><!– bomb layer –>
<script src= "tabview.js"/><!– slideshow prototype –>
<script src= " Slider.js "/><!– slide –>
<script src=" Logica.js "/>
<script>
$.ondomready (function () {
___logica.start ();
});
</script>

First of all, the handwriting of a large number of JS files will each occupy a separate HTTP request, in the person, this scene, Slider.js inherited from Tabview.js, so to focus on their order, third, if others in the other parts of the page also use a calendar or a slide, and add two of the same JS tag? Actually, speaking of this, we can already see the shadow of the big project team development, in an iterative and its frequent project, the developer needs to complete a complex page in a short time a function of the development, and can not affect the other features of the page, after all, each add a function, QA MM will be associated with all the functions of the return, can be hard for our QA mm. In this case, the development of one feature may be parallel to the development of other functions of the same page. Each other does not belong to the same project team, nor is it aware of the other's implementation. This pattern is often encountered by many people development, conflicts are mostly generated, each function appears to be correct alone, combined to create conflicts and bugs, debugging bugs requires two engineers at the same time, very troublesome. Very, when the component upgrades, for example, tabview.js inherit from Tab.js again, then go to contact each engineer, will each reference tabview.js place before adding a tab.js, very troublesome. We say that the conflict caused by this multiplayer collaboration model is also a kind of code pollution, because everyone can only control a place like the TMS block, the final page is what kind of, do not know. Moreover, this kind of the vigorous reference JS, also will block the page to load, occupies the HTTP request, affects the performance.

In view of this, Yui will JS dynamic introduction mechanism also merged into its sandbox design, I want to cite just a name, such as Slider.js, he relies on tabview.js,tabview.js rely on tab.js, so I just quote a name "slider" things Can, Don't worry about what he relies on, not to mention how to introduce to the page, Yui help us to fix:

<script>
Tb.addmoudle ({
___logica:{
______fullpath: ' Logica.js ',
______requires:[' Slider ']
___}
). Use (' Logica ', function (Y) {
___logica.start ();
});
</script>

When we look at the final form of the page, we see only these short, consistent JS code snippets buried in every corner of the page. Easy to understand, this code does not have to be like a long block of code into one line. (more details refer to code contamination caused by a front-end weak architecture)

5, the number of granular or HTTP requests
This is indeed a pair of contradictions, Granulation brought the project development, management, and code reuse efficiency, but also introduced more HTTP request number, fortunately Yui provides a combo, you can merge all the HTTP request into one. Yui introduced in the time to configure the combo property can be, the high granularity of the request to reduce the number of times more than a moment. In the previous Yahoo relationship, in the case of Yui2 and yui3pre coexist, can reduce the request to 4, YUI2 and 3 each one seed, each one combo. Of course this is in hack off Yui loader premise. Yui default will not merge not Yui file (more details can be read based on Yui team development). Even so, we can still control our number of HTTP requests, in the case of Hack Yui, can solve some of the performance problems.

6, lazy load or instant load instant execution
As mentioned above, the logic relies on the sandbox, sandbox depends on the JS file is delayed loading, which leads to a problem, when the page is large, will wait for the page JS loaded before rendering action, such a poor user experience, and real-time loading even if the operation can be rendered out of the module immediately after the rendering action, When the speed of a certain time, the two seem to be a pair of irreconcilable contradictions, Yui dynamic loading mechanism more compromise to deal with this problem, A logic requires a.js,b logic and b.js,a logic is executed only after the a.js load is complete. Regardless of whether the b.js is loaded, and when a needs a.js and B.js, a waits for a.js and b.js to be loaded to complete before executing, and B logic only needs to determine if the b.js is currently loaded, if B.J S has been introduced into other modules and B can be executed immediately. However, it is certain that all of the JS must be introduced after the Domready, that is, in any case, the action of the rendering must be in the HTML structure of the page to start after the implementation of the user experience or there will be loss.

7, interface-oriented design or DOM-oriented design
We know that the plug-in custom of jquery is to load all the actions into a $ (' #id '), and use it as long as it performs a similar $ (' #id '). Init (). This looks concise, the logic of the developer has never left the "node", it is easy to understand, and the YUI3 node extension is not so convenient, from the pre version of Yui3 to the official version of the node extension method is constantly modified (see more details here: Extended Yui3 Node timer), this can also be seen Yui designers in the node extensibility design of the tangle and distress: Do not allow developers to expand node nodes? Probably because the designers of the prototype congenital defects fear. For now, designers are not entirely out of the tangle, although the first preview version of the node extension is much more convenient than the YUI3 one, and developers still can't extend the node as gracefully as the jquery plugin. Instead, Zakas is more focused on the design of the widget interface, where, compared to JQUERY,YUI3, it has unlimited advantages, because in Yui3, the component is not just a component, but a flesh-and-blood life, he can be born, can grow, can be transformed, Can die, components in these complex run-time environment to temper themselves, so a complex page in the YUI3 technology system, into a myriad of components linked to the ecosystem, the chain of design innovation and New Horizons is the other JS framework can not be exceeded in any case. More details on YUI3 component development can be referenced: Yui3 component Development 1 and Kerjun on D2 share "from Yui2 to Yui3 look at the evolution of the front end"

8, a slim figure or a large body
When it comes to this, there will probably be a lot of people making bricks. In fact, the jquery and Yui belong to two different types of JS framework, a slim slender, a Muntong such as mountains, between the two in fact, there is no misery, just the use of a different, similar to the use of the framework of jquery is a blog-level small site, especially for single development, code write once no longer modified, and very suitable for beginners to learn to use, to bring self-confidence to beginners. Yui is the use of enterprise-level projects in the team development, project maintenance cycle far more than the development cycle, so Yui performance must be jquery,jquery than the life of the Yui, not the most excellent, only the most suitable. Of course, this naturally can not block my personal love for the fascinating jquery, as long as we can learn from each JS framework, can improve their ability to do the front-end architecture, OK.

Said so much, in fact, there is only one point of view, nobody is perfect, the framework of the framework, the shortcomings must be weighed. Above yy, welcome to Pat Bricks!