Home » JavaScript » Js-AMD-CMD- dependency differentiation

Js-AMD-CMD- dependency differentiation


the main differences between the two are as follows:




  1. positioning differences.RequireJS to become the module loader browser, but also as Rhino / Node environment module loader.Sea.js focuses on Web browser, at the same time through the Node propagation mode can easily run.

    in Node environment

  2. follow the norms of different.RequireJS follow AMD (asynchronous module definition) specification, Sea.js (general module definition) follow the CMD specification. The specification is different, resulting in the two different API.Sea.js CommonJS and Node Modules/1.1 closer to the Modules specification.



  3. To promote the concept of

    there were differences in.RequireJS try to modify their own third party libraries to support RequireJS, only a few communities adopt.Sea.js not strong push, the independent package to "all rivers run into sea has a" mature packaging strategy.



  4. there are differences in support for development debugging..Sea.js is very concerned about the development and debugging of code. There are nocache, debug and other plug-ins for debugging..RequireJS has no obvious support for this aspect of.



  5. The

    plug-in mechanism is different..RequireJS takes the form of reserving interfaces in the source code, the plug-in type is relatively single,.Sea.js adopts the universal event mechanism, and the plug-in type is more abundant..



there are many differences, involving specific ways of use and implementation of the source code. Welcome interested parties to study and express their views,.


in short, if RequireJS is a Prototype class library, then Sea.js is committed to becoming the jQuery class library.







I can say the difference between AMD/CMD and my opinion:


it is necessary to briefly mention the main differences between the two. CMD advocates relying on the nearest and can write any line of dependency into your code, for example:


define (function (require, , exports, , module)  {
var, a, =, require ('./a')
a.doSomething ()
var, b, =, require ('./b')
b.doSomething ()
})




code at run time, the first is not know rely on, all need to traverse the require keyword, find out behind the dependence. The specific approach is function toString, following the require keyword matching on regular. Obviously, this is a sacrifice performance for more convenient method >.


and AMD is dependent on the front. In other words, before parsing and executing the current module, the module author must specify the modules that the current module relies on. The performance is represented by the call structure of the require function:


define (['./a', './b'], function (a, b) {
a.doSomething ()
b.doSomething ()
})




The code in the once running here, can immediately know the dependence. Without the need to traverse the whole function body find its dependence, so the performance has improved, disadvantage is that developers must explicitly specify dependencies -- which would make greater development work, for example: when you wrote the letter body of hundreds of thousands of lines and suddenly found a need to increase the dependence, you have to go back to the top of the function to add.
array dependence


careful readers may find a dependent part to the current position I discussed AMD and CMD thoughts, only discuss the "hard dependence", which is executed depends on the former certainly needs, but this is not all. Sometimes the situation is this: >

 >// function in vivo
if (status) {
a.doSomething ()
}




in this function in vivo, may depend on the A, it may not depend on a, I have to rely on this may become a "soft dependence". For the soft on when the hard course can be directly dependent, but this is not the economy, because of the dependence is not necessarily dependent, may have loaded here and actually not used.

for soft dependency processing, I recommend relying on the implementation of the prefix + callback function. The example above is simply as follows:


 >// function in vivo
if (status) {
async (['a'], function (a) {
a.doSomething ()
})
}




so far, you can summarize the scheme that was derived from commonJS. To design the module loading mechanism at the browser side, you need to consider the dependency issue,.

let's divide dependencies into two categories, "strong dependence" - "yes" and "weak dependency" - may need.

for the strong dependence, if the performance of priority, taking into account the design reference dependent front module loader you, I also appreciate this scheme; if considering the development of cost priority, consider according to your nearest dependent design module loader. < /span>

for weak dependencies, you only need to overwrite the weak dependencies into the callback function, and then.

If I want to achieve a module loader, I will rely on the front, weak dependence using asynchronous callback function in the form of other methods I think are just syntactic sugar. This alone is enough.


turn from: http://www.zhihu.com/question/21347409#answer-2323656

Latest