The biggest difference between Seajs and Requirejs U_u2013-06-20 16:21:12The mechanism for executing the module is very different.
-----------------------------------
Because Requirejs is the AMD specification that executes, all dependent modules are executed first.
Using Requirejs to define the module by default is clearer in terms of understanding, but individuals still prefer require ('./mod1 ').
define ([' Dep1 ', ' dep2 '], function (DEP1, DEP2) {
Define the module value by returning a value.
return function () {};
});
Hope that the article did not fraught, thank you @Jaward Andy's comments, please read more comments, comments more material ...
---------------------------------------------------------------------------
Seajs's attitude towards the module is lazy execution, while Requirejs's attitude to the module is pre-executed
Don't understand? Let's give an example.
The following modules are loaded via Seajs/requirejs, what happens to the results?
Define (function (Require, exports, module) {
Console.log (' Require module:main ');
var mod1 = require ('./mod1 ');
Mod1.hello ();
var mod2 = require ('./mod2 ');
Mod2.hello ();
return {
Hello:function () {
Console.log (' hello Main ');
}
};
});
Can you guess?
Try Seajs results first.
Require Module:main
Require MODULE:MOD1
Hello Mod1
Require MODULE:MOD2
Hello Mod2
Hello Main
Again, it's Requirejs's execution results.
Require MODULE:MOD1
Require MODULE:MOD2
Require Module:main
Hello Mod1
Hello Mod2
Hello Main
|
| God horse situation? Are you kidding me? |
Requirejs you hang of me, this is why I do not like Requirejs reason, the pit hidden too deep.
Finally understand Yuber said the sentence: "Requirejs is no obvious bug,seajs is obviously no bug" what does it mean?
So we come to the conclusion (test using Seajs 2.0.0 and Requirejs 2.1.6 respectively)
-------------------------
SEAJS only executes the module when it really needs to be used (dependent)
Seajs is the correct way to load modules asynchronously, but the order in which the modules are executed is strictly in the order in which they appear in the code (require), so it is more logical. What do you say, Requirejs?
And Requirejs will execute the (dependent) module as soon as possible, equivalent to all the require are advanced, and the order of the module execution is not necessarily 100% is first mod1 again MOD2
So you see that the order of execution is completely different from what you expected! Shake It ~ requirejs!
For detailed code, please refer to
-------------------------
SEAJS Test Load/execute module
Requirejs Test Load/execute module
Postscript
-------
Note what I'm talking about here is executing (actually running the code in the Define) module, not the load (load file) module.
Module loading is parallel, no difference, the difference lies in the timing of the implementation of the module, or is resolved.
To illustrate the problem of blocking, Cui Hua
|
| Pre-execution of Requirejs |
Note the huge pinyin-dict.js module, taken from pinyin.js, copied n times to increase its "weight", enhance the presentation effect, if you are interested, you can try it yourself.
It is clear that Requirejs's approach is to load all dependent modules in parallel, and after parsing, then start executing other code, so the execution results will only "pause" 1 times, and complete the process will be faster than SEAJS.
While Seajs is the same as loading all dependent modules in parallel, but does not immediately execute the module, wait until the real need (require) to start parsing, where time is spent, because the module in this special case is huge, resulting in a "pause" 2 times, this is what I call "lazy execution" in the Seajs.
Finally thank you for all the suggestions, I do not say here Seajs and Requirejs which better, just to illustrate the difference between them, all kinds of trade-offs please according to the actual situation to set, hope to help everyone. Bull View:
1,
I personally feel requirejs more scientific, all dependent modules to be executed first. If the A module relies on B. When the execution of a dosomething () in a, then to rely on the execution of B module require (' B '), if the B module error, how to rollback dosomething operation?
Import, include, and useing in many languages are first performed by the imported classes or modules. What is the point of executing the current module if the module being imported has a problem with an error?
In short, all the modules loaded, are currently to be used, why dynamic to do? This question can be summarized as whether the load execution of a module is static or dynamic. If it is executed dynamically, the program execution of the page will be affected by the execution of the current module. And as the landlord said, the dynamic execution of the overall time is slower than the static one execution.
Landlord said Requirejs is a pit, because you do not understand the AMD "asynchronous module" definition, the dependent module must precede the current module execution, and no dependency of the module, can not be successively. In the landlord's example, assuming that mod1 and mod2 a certain day of dependence, such as in a certain version, MOD1 relies on mod2 (which is entirely possible), this time seajs lazy implementation will not have a problem? There is no problem with Requirejs and there is no need to modify the current module.
In JavaScript, which is a naturally asynchronous language, the module is lazy to execute, which makes people very incomprehensible. Imagine factory is a module factory, and rely on dependencies is the raw material of the factory, in the factory production, is the first raw materials in its own factory processing, or the raw materials of the factory to move to the current factory when need, when processing , which overall time is more efficient? It is obvious that Requirejs,requirejs is loaded and ready to use. In response to a user's operation, the current factory is in production, when the need for some kind of raw materials, suddenly to stop production, to start raw material processing, this is not to make the current factory very dry?
Ignore this for a while, and then see who is more reasonable when the modular definition is added to the ECMA specification.
2,
AMD Runtime Core thinking is "early executing", which is the early implementation of dependency. This good understanding:
Main.js
define ([' A ', ' B '], function (A, b) {
Running to this point, a.js and b.js have been downloaded (the Loader running in the browser must be so);
A, B two modules have been executed, directly available (this is the characteristics of AMD);
return function () {};
});
Personally, this feature of AMD is good and bad:
First, early execution of dependencies can identify errors early. In the above code, if an exception is thrown in a module, then Main.js will receive an error before calling the factory method, factory will not execute, and if the dependency is performed on demand, the result is: 1) No error occurs when a branch using the A module is not entered, 2) when an error is encountered, the Main.js The factory method is probably half done.
In addition, early implementation of dependencies often leads to a better user experience and is prone to waste. For example, module a relies on another module B, which needs to load the data asynchronously, and executing B early can make the wait time shorter, and if B is not used at the end, the bandwidth and memory overhead are wasted; In this scenario, the on-demand execution of dependencies avoids waste, but leads to longer wait times.
I personally prefer AMD to this approach. To cite a less appropriate example: Chrome and Firefox for a better experience, for some types of files, click will ask whether to save, this time has actually started the download. Sometimes wait a long time to confirm, will be happy to find that the file has been good, if the point is canceled, the browser will cancel the download, the downloaded part is wasted.
Https://www.imququ.com/post/amd-simplified-commonjs-wrapping.html
The biggest difference between Seajs and Requirejs
