Comparison of the differences between SeaJS and RequireJS_AngularJS

"History is not the past, history is happening now. With the rapid development of specifications such as W3C and browsers, front-end modular development will gradually become infrastructure. Everything will eventually become history, and the future will be better."—— Quoting the last paragraph of Yu Bo's original article, I personally agree very much. Now that we talk about the "future", I personally think that if the front-end js module continues to develop, its module format is likely to become a standard specification for the future WEB, resulting in multiple implementation methods. Just like the JSON format, it eventually became a standard and was implemented natively by browsers.

Who is more likely to become the future asynchronous module standard? SeaJS follows the CMD specification, and RequireJS follows the AMD specification. Let’s start with these two different formats.

CMD

CMD module dependency declaration method:

Copy code The code is as follows:

define(function (require) {
var a = require('./a');
var b = require('./b');
// more code ..
})

CMD dependencies are declared nearby and declared through the internal require method. But because it is an asynchronous module, the loader needs to load these modules in advance, so all dependencies in the module need to be extracted before the module is actually used. Whether it is extracted on-the-fly by the loader or pre-extracted through automated tools, this dependency declaration format of CMD can only be achieved through static analysis, which is the disadvantage of CMD.

Disadvantages of CMD specification

Cannot be compressed directly: require is a local variable, which means 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 module's dependencies.
There are additional conventions for module writing: path parameters cannot be subjected to string operations and cannot be replaced by variables, otherwise the loader and automation tools will not be able to correctly extract the path.
Contracts outside the specification mean more documentation, unless they are also part of the specification.

Note: SeaJS static analysis is implemented by putting the module package toString() and then using regular expressions to extract the require part to obtain the dependent module path.

AMD

AMD module dependency declaration method:

Copy code The code is as follows:

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

AMD dependencies are declared in advance. The advantage of this advantage is that dependencies do not need to be statically analyzed. Both loaders and automation tools can directly obtain dependencies. The definition of specifications can be simpler, which means that more powerful implementations may be produced. This has a great impact on loaders and automation. Analytical tools are beneficial.

Disadvantages of AMD specifications

Declaration of dependencies in advance is not so friendly in code writing.
There are certain differences between modules internally and NodeJS Modules.
The second point requires special explanation. In fact, neither CMD nor AMD's asynchronous module can be consistent with the synchronous module specification (NodeJS's Modules). Only one is more like a synchronous module than the other. To convert AMD to a synchronized module, in addition to removing the wrapper of the define function, you need to use require in the header to declare the dependencies, while CMD only needs to remove the wrapper of the define function.

Summary

In terms of specifications, AMD is simpler and more rigorous, with wider applicability. With the strong promotion of RequireJS, it has almost become the de facto asynchronous module standard abroad, and major libraries have also successively supported AMD specifications.

But from the perspective of SeaJS and CMD, it has also done a lot of good things:

1. Relatively natural dependency declaration style
2. Small but beautiful internal implementation
3. Intimate peripheral function design
4. Better Chinese community support

If possible, I would like to see SeaJS also support AMD, in order to be consistent with the front-end community environment. In the end, the majority of developers will be happy.