Yui3 sacrifices and concessions in the framework design

Believe that every front-end engineers have their favorite JavaScript frame, say emotion or faith,JavaScript framework to bring people not only convenient development, but also a pure logical beauty, whether it is the elegant simplicity of jquery, Or Yui magic-like sandbox, all make us produce infinite imagination. However, the JS framework is bound to be unable 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, Manual introduction or dynamic loading

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, and so on, the third, dynamic loading is conducive to the semantics of the page code, which allows developers to 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, the logical start of a single entry or sand box

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.