"History is not the past, history is being staged. With the rapid development of W3C and browsers, front-end modular development will gradually become infrastructure. Everything will eventually become history, and the future will be better." - I personally agree with the last paragraph of Yu Bo's original text. Since we talk about the "future", I personally believe that if the front-end js module continues to develop, its module format is likely to become a standard specification for future WEB and produce multiple implementation methods. Just like the JSON format, it eventually becomes standard and is implemented natively by the browser.
Who has the best standard for asynchronous modules to become the future? SeaJS follows the CMD specification, RequireJS follows the AMD specification, let's start with these two different formats.
CMD
CMD module dependency declaration method:
The code copy is as follows:
define(function (require) {
var a = require('./a');
var b = require('./b');
// more code ..
})
CMD dependencies are declared nearby and are declared through internal require methods. However, because it is an asynchronous module, the loader needs to load these modules in advance, so before the module is actually used, all dependencies in the module need to be extracted. Whether it is loader extraction or pre-extracting through automated tools, this dependency declaration format of CMD can only be implemented through static analysis, which is the disadvantage of CMD.
Disadvantages of CMD specifications
Cannot directly compress: require is a local variable, which means that it cannot be compressed directly through the compression tool. If the require variable is replaced, the loader and automation tools will not be able to obtain the dependencies of the module.
The module has an additional convention: the path parameters cannot be string operations, and variables cannot be used instead, otherwise the loader and automation tools cannot extract the path correctly.
Conventions outside the specification mean more documentation unless they are also part of the specification.
Note: SeaJS static analysis implementation is to use the regular extraction requirement part to get the dependency module path.
AMD
AMD module dependency declaration method:
The code copy is as follows:
define(['./a', './b'], function (a, b) {
// more code ..
})
AMD's dependencies are declared in advance. The advantage of this advantage is that dependence does not require static analysis. Both the loader and the automation tool can directly obtain dependencies. The definition of the specification can be simpler, which means that more powerful implementations may be generated, which is beneficial to both the loader and the automation analysis tool.
Disadvantages of AMD specification
Dependency advance declarations are not so friendly in code writing.
There is a certain difference between the module inside and the Modules of NodeJS.
The second issue needs to be explained in detail. In fact, neither CMD nor AMD's asynchronous modules can be consistent with the synchronization module specification (NodeJS's Modules), only who is more like a synchronization module than who is. To convert AMD to a synchronization module, in addition to removing the package of the define function, you need to use require in the head to declare the dependency, while CMD only needs to remove the package of the define function.
Summarize
In terms of specification, AMD is simpler and rigorous, and has a wider applicability. With the strong promotion of RequireJS, it has almost become a de facto asynchronous module standard abroad, and major libraries have successively supported AMD specifications.
But from SeaJS and CMD, we have also done a lot of good things:
1. Relatively natural dependency statement style
2. Small and beautiful internal realization
3. Careful peripheral function design
4. Better Chinese community support
If possible, I hope to see SeaJS also supports AMD, and the ultimate happiness of developers is the majority of developers.