Comparison of differences between SEAJS and Requirejs

This article mainly introduces the difference between Seajs and Requirejs, this paper compares the shortcomings of the CMD specification and AMD specification, and makes a summary, the need of friends can refer to the following

"History is not the past, history is unfolding." With the rapid development of the specifications and browsers, the development of the front-end modularization will gradually become the infrastructure. All will become history, the future will be better. "--quoting the last paragraph of Yuber's original text, I personally agree. Since talking about "the future", I personally think: if the front-end JS module continues to develop, its module format is likely to become the future of the WEB a standard specification, to produce a variety of implementation methods. Just like the JSON format, it eventually becomes standard and is natively implemented by the browser.

Who is more likely to be the standard for future asynchronous modules? Seajs follows the CMD specification, Requirejs follows the AMD specification, starting with these two different formats.

Cmd

The CMD module relies on declarative methods:

Define (function  (require) {    var a = require ('./a ')    ; var b = require ('./b ')    ; // More code:})

The CMD dependency is the nearest statement, declared by the internal require method. But because it is an asynchronous module, the loader needs to load the modules ahead of time, so the module needs to extract all the dependencies in the module before it is actually used. Whether the loader is extracted on the fly or is pre-extracted through automated tools, the CMD-dependent declaration format can only be implemented by static analysis, which is where CMD is the disadvantage.

The drawbacks of the CMD specification

cannot be compressed directly: Require is a local variable, which means that it cannot be compressed directly through the compression tool, and if the Require variable is replaced, the loader and the automation tool will not be able to acquire the dependency of the module.
There are additional conventions for module writing: path parameters cannot be used for string operations, and variables cannot be substituted, otherwise the loader and automation tools will not be able to extract the path correctly.
Conventions outside the specification imply more documentation, unless they are part of the specification.

Note: SEAJS static analysis implementation is to take the module packet ToString () after using the regular extraction of the require portion of the module to get dependent path.

Amd

AMD modules rely on declarative methods:

function (A, b) {    // more code:})

AMD's reliance is stated in advance. The benefit of this advantage is that relying on no static analysis, both the loader and the automation tool can be very straightforward to get to the dependency, the definition of the specification can be simpler, which means that it is possible to produce a more powerful implementation, which is beneficial to the loader and automated analysis tools.

The drawbacks of AMD specifications

Relying on advance declarations is not so friendly in code writing.
There are some differences between the Modules of the module and the NodeJS.
The question on the 2nd requires special clarification. 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 the synchronization module than anyone else. AMD to convert to a synchronization module, in addition to removing the Define function of the package, you need to use require in the head to declare the dependency, and CMD only need to remove the Define function package.

From a normative standpoint, AMD is simpler and more rigorous, more adaptable, and, driven by Requirejs's strength, has almost become a de facto asynchronous module standard in foreign countries, and each major class library supports AMD specifications in succession.

But from Seajs and CMD, there are a lot of good things to do:

1. A relatively natural reliance on declarative style
2, small and beautiful internal implementation
3, intimate design of peripheral function
4. Better support for Chinese community

If possible, I would like to see Seajs also support AMD, in keeping with the front-end community environment. The ultimate happiness is the vast majority of developers.

Comparison of differences between SEAJS and Requirejs