The Mod and the Requirejs/seajs.

The purpose of this article is to make home better understanding of the Mod, the reason for the introduction of REQUIREJS/SEAJS contrast is mainly to require a clearer comparison of application scenarios, not to compare the pros and cons, Requirejs and SEAJS are modular long road pioneers, salute them!

A mod for an engineered living

Modularity is a way of dealing with the decomposition of a complex system into a better manageable module, which divides the system code into a series of single, highly decoupled and replaceable modules that are modular to make the system more maintainable and easy to use.

JavaScript does not provide developers with a way to manage modules in a concise, methodical way. From a point of view, mod and REQUIREJS/SEAJS are consistent, providing developers with a set of JavaScript modular development solutions that make JavaScript's modular development easier and more natural. However, there are huge differences in the implementation process.

MoD is strictly not an independent modular framework, it is designed to be used as a front-end engineering modular programming of JAVASCRIPT support, need to work with automation tools, back-end framework to use, in order to provide engineers with a similar nodeJS-like development experience, It also has good performance on the line.

The Requirejs and Seajs are primarily Web browser-side module loaders that rely on JavaScript runtimes to support module definitions, dependency analysis, and load functions.

The development experience of class CommonJS

Requirejs complies with the AMD specification and SEAJS complies with the CMD specification. The AMD/CMD specification uses the "async module definition" approach, which brings great inconvenience to development, all synchronous code needs to be modified to be asynchronous, whether we can use the "CommonJS" approach in front-end development, and developers can use natural, The easy-to-understand module definition and invocation method, does not need to focus on whether the module is asynchronous, does not need to change developer's development behavior. The answer is, of course, yes, MoD does not comply fully with the AMD/CMD specification, and is designed to provide developers with a simpler and more natural development experience.

Module definition

Mod uses define to define a module:

define (id, factory)

Factory provides 3 parameters: require, exports, module, reference and export for modules.

in the normal development, we do not need to focus on the module definition, the tool will automatically define the JS packaging processing :

JS Source

Common/widget/menu/menu.jsVar$=Require(' Common:widget/jquery/jquery.js ');Exports.Init=function(){$('. Menu-ui ul Li a '). Click(function(event) { var self = this; $('. Menu-ui ul Li A.active ').  Removeclass(' active '); $(self).  AddClass(' active '); event.  Preventdefault(); }); }; 

Post-compilation Code

Define(' Common:widget/menu/menu.js ',function(Require,Exports,Module){Var$=Require(' Common:widget/jquery/jquery.js ');Exports.Init=function(){$('. Menu-ui ul Li a '). click (function (event ) {var self =  This$ ().  Removeclass ( ' active ' $ (self).  Addclass ( ' active ' event. Preventdefault (); ); };                

module invocation

MoD automatically loads dependent dependencies before the module is initialized. So when we need a module, we just provide a module name to get:

require (id)

Because the required modules are preloaded, require can return the module reference immediately (synchronously). whether in script or inside the module , the engineer can safely load the module through require, without having to consider when the asynchronous interface is invoked when the synchronization interface is used.

Avoid the modularity of performance issues

REQUIREJS/SEAJS supports features such as anonymous closures, dependency analysis, and module loading through the JavaScript runtime, and dependency analysis requires a regular match to the module's dependencies at JavaScript runtime. Then follow the chain of dependencies (that is, along the dependency layer declared by the module until there is no dependency) to load all the modules that need to be loaded in order one by one, when the module is a lot of complex dependencies, it can seriously affect the performance of the page. The MoD avoids the above problems with the following design:

• Automatically add define closures via tools, no support for anonymous closures on line
• Automatic processing of dependencies through tools without the need for dynamic processing dependencies on the line
• Automatic insertion of script via back-end template, no module loading on the line through the front-end frame

Through the above design, the MoD is very streamlined, the entire file only more than 100 lines, compared to the next Requirejs has more than 2000 lines, SEAJS has nearly 1000 lines.

Avoid the great inconvenience of modular packaging deployment

After the modular development through REQUIREJS/SEAJS, the merging of static resources (packaging) will become very inconvenient and obscure, each file can only have a module, whether it is "combo plug-in" or "flush plug-in", we need to modify the modular call code, This is undoubtedly compounded by the need for engineers not only to focus on the module definition at the time of development, but also to focus on the appropriate modules to be loaded in a request, which is designed to improve development efficiency and reduce maintenance costs, but we find that such a modular approach does not actually reduce maintenance costs, In a way, the whole project is more complicated. With MoD, the engineer only needs to configure the merge policy in the configuration file and does not need to focus on other details, the mod automatically handles the dependencies and merges the information and loads and prepares the module's static resources and dependent modules before the module is initialized.

Adaptive performance Optimization

The entire MOD modular process is as follows:

The module is compiled with automated tools, including adding closures to JavaScript modules, documenting the deployment path of each static resource, and generating a Resource table (resource map), as shown below.

{"Res":{"Demo.js":{"uri":"/static/js/demo_33c5143.js","Type":"JS","Deps":["Demo.css"],"Pkg":"P0"},"Index.html":{"uri":"/index.html","Type":"HTML","Deps":["Demo.js","Demo.css"]},"Script.js":{"uri":"/static/js/script_32300bf.js","Type": "JS"  "pkg" :  "P0" } }  "pkg" : { " P0 ": {" uri ": /static/pkg/aio_ 5bb04ef.js "" type ": " JS " Span class= "NT" > "has" : [ "demo.js"   "script.js" ],  "Deps" : [ "demo.css" ] } } }      

All packaged resources will have a PKG attribute pointing to the resources in that table, and this resource is exactly the packaging strategy we configured. With this information, we can manage and control the loading of modules through the MoD framework (MOD and backend framework). MoD modularity can be very flexible to adapt to a variety of performance optimization scenarios, we can also through the monitoring module call situation, automatically generate the best packaging configuration, so that the site can be adaptive optimization.

Summarize

MOD provides an integrated modular solution, more from an engineering, automation perspective, requirejs/seajs more independent and flexible.

Reference: Http://fex.baidu.com/blog/2014/04/fis-modjs-requirejs-seajs/?utm_source=tuicool&utm_medium=referral

http://www.tuicool.com/articles/yuY36n

The Mod and the Requirejs/seajs.