The difference between AMD and CMD

World Link: https://www.zhihu.com/question/21347409/answer/17959757Source: Copyright belongs to the author, please contact the author for authorization. It is necessary to briefly mention the main difference between the two, the CMD is highly dependent on the nearest, you can put the dependency into any line of your code, for example: define (function(Require, exports, module) {varA = require ('./a ')) a.dosomething ()varb = require ('./b ')b.dosomething ()}) code at run time, the first is not aware of dependencies, you need to traverse all the require keywords to find the dependencies behind. This is done by using the function ToString to match the dependency after the Require keyword. Obviously, this is a way to sacrifice performance in exchange for more development convenience. AMD is dependent on the predecessor, in other words, before parsing and executing the current module, the module author must indicate the module on which the current module depends, as shown on the call structure of the Require function: define (['./a ', './b '],function(A, b) {a.dosomething () b.dosomething ()}) The code is immediately aware of dependencies once it is run here. Instead of traversing the entire function body to find its dependencies, performance is improved, and the downside is that developers have to explicitly indicate dependency-which can make the development effort larger, such as when you write hundreds of thousands of lines in the body of a function, and suddenly find that you need to add a dependency, You have to go back to the top of the function to add this dependency into the array. The attentive reader may find that the current position of the AMD and CMD ideas that I am talking about depends on the "hard-to-rely", which is definitely required before execution, but this is not the case. Sometimes this is the case://function Body:if(status) {a.dosomething ()} In this function body, may depend on a, may not depend on a, I make this possible dependence "soft dependence". For soft dependencies, of course, it can be done directly when hard-dependent processing, but this is not economical, because the dependency is not necessarily, it is possible to load the dependency here and actually no use. For soft-dependent processing, I recommend relying on the predecessor+the implementation form of the callback function. The above example is briefly stated as follows://function Body:if(status) {Async ([' A '],function(a) {a.dosomething ()})} It is now possible to summarize the scheme derived from Commonjs. In the browser side to design the module loading mechanism, you need to consider the problem of dependency. Let's start by dividing the dependencies into two, "strong dependencies"--definitely need and "weak dependencies"--that might be needed. For strong dependencies, if you want performance first, consider designing your module loader with reference to pre-dependent thinking, and I personally prefer this scenario, and consider designing your module loader based on the idea of proximity, if you consider development cost first. For weak dependencies, you only need to overwrite the weakly dependent portions into the callback function. If I were to implement a module loader now, I would strongly rely on pre-dependencies, weak dependencies in the form of asynchronous callback functions, and other methods I think are just syntax sugar, that's all that's enough. 

The difference between AMD and CMD