If you've ever heard of JS modularity, then you should have heard or commonjs or AMD or even cmd, and I've heard it before, but I've heard it before.
Now look at what these specs are, and why. A, COMMONJS  COMMONJS is for the performance of JS to develop specifications, because JS does not have the function of the module so CommonJS came into being, it hoped that JS can run anywhere, not just the browser. commonjs can have a certain influence, I feel absolutely inseparable from the popularity of Node, but oh, Node,commonjs, browser and even the internet is what the relationship between, I found an appropriate figure: |---------------Browser-----------------------| |--------------------------CommonJS----------------------------------| | bom | | DOM | | ECMAScript | | FS | | TCP | | Stream | | Buffer | |........| |------------------| |--------------------------------------- The module defined by Node--------------------------------------------------| commonjs is divided into: {Module reference (require)} {module definition ( Exports)} {module identification (modules)} require () is used to introduce external modules, exports objects are used to export methods or variables of the current module, the only exportThe module object represents the modules themselves. For example, we can use the: copy code 1//SUM.JS2 exports.sum = function () {... Do add operation ...}; 3 4//calculate.js5 var math = require (' Sum '), 6 exports.add = function (n) {7 return math.sum (val,n); 8}; Copy code Although node follows the COMMONJS specification, it does some trade-offs and fills in some new stuff. However, said Commonjs also said node, then I think I have to understand the NPM. NPM, as node's package Manager, is not to help node with the installation of the dependency package, it must also follow the COMMONJS specification, which follows the package specification (or theory). commonjs Wiki speaks about its history, and also introduces modules and packages. Second, Amd commonjs is mainly for JS in the back end of the performance of the formulation, he is not suitable for the front-end, why so to say? This needs to analyze the browser-side JS and server-side JS are the main things to do, what is different: ---------------------------------------server-side JS | browser-side JS------------------------------------------- & nbsp The same code needs to be executed multiple times | code needs to be distributed from one server side to multiple clients &NBSP ;  CPU and memory resources are bottlenecks | Bandwidth is bottleneck load-loading from disk | loading requires a network load --------------------------------------------------------------------------------- ------------------------------ So, AMD (asynchronous module definition) appears, it is mainly for the front-end JS performance specification.  AMD has only one interface: Define (id?,dependencies?,factory); it to make all the dependencies (DEP) when declaring the module, and also as a formal parameter to factory, like this: 1 define ([' Dep1 ', ' Dep2 '],function (DEP1,DEP2) {...}); If there is no dependency, define a simple module, the following is OK: 1 define (function () {2 var exports = {};3 & nbsp Exports.method = function () {...}; 4 return exports;5}); , here are define, the things wrapped up, that node implementation how did not see there is a define keyword it, it also want to wrap things up ah, in fact, It's just that node implicitly wraps it .... requirejs is the AMD specification. This has the Chinese version of the wiki of AMD, said a lot of very detailed things, when used can be viewed: AMD wiki Chinese version three, cmd name of Yuber wrote Seajs, is to follow his proposed CMD specification, and AMD pretty similar, but it feels more convenient to use, the most important is the Chinese version, everything: Seajs official doc 1 define (function (Require, Exports,module) {...}); used Seajs Bar, this is not strange, right. Yuber Explanation of the difference between AMD and CMD:      AMD is the normalized output of the module defined by REQUIREJS during the promotion process. cmd is the normalized output of the module defined by SEAJS in the process of generalization. similar to the CommonJS modules/2.0 specification, is bravojs in the promotion process of the module definition of standardized output still a lot?? These specifications are intended for the modular development of JavaScript, especially on the browser side. at present, the implementation of these specifications can achieve the purpose of browser-side modular development. difference: 1. For dependent modules, AMD is executed ahead of time, and CMD is deferred execution. However, starting from 2.0, Requirejs is also changed to be deferred (depending on the way it is written and handled differently). CMD respected as lazy as possible. 2. The CMD is highly dependent on the nearest, AMD is highly dependent on the predecessor. See Code:
- Cmd
- Define (function (Require, exports, module) {
- var a = require ('./a ')
- A.dosomething ()
- 100 lines are omitted here
- var B = require ('./b ')//dependency can be written near
- B.dosomething ()
- // ...
- })
- The default recommended by AMD is
- define (['./a ', './b '), function (A, B) {//dependencies must be written at the beginning.
- A.dosomething ()
- 100 lines are omitted here
- B.dosomething ()
- // ...
- })
While AMD supports the syntax of CMD, it also supports passing require as a dependency, but Requirejs's author defaults to the preferred notation, which is the default definition of the module in the official document. 3. AMD's API defaults to one when multiple uses, the CMD API is strictly differentiated, advocating a single responsibility. For example, AMD, require global require and local require, are called require. In CMD, there is no global require, but according to the completeness of the module system, provide seajs.use to realize the loading and starting of the module system. CMD, each API is simple and pure. 4. There are also some details of the difference, the specific definition of the specification is good, not much to say.
AMD & CMD