JavaScript Module specification AMD specification and CMD specification _javascript tips

Modularity refers to the systematic decomposition of a problem in the process of solving a complex problem or a series of mixed problems, according to a sort of thinking. Modularity is a way of dealing with complex systems that decompose into manageable modules that are more reasonable and maintainable for code structures. It can be imagined that a huge system code, being integrated and optimized to be segmented into a logically strong module, is a kind of meaning for software. For the software industry: decoupling software system complexity, so no matter how large the system, can also be management, development, maintenance become "reasonable to follow."

There are some professional definitions for modularity: Modularity is a property of a software system that is decomposed into a group of highly cohesive, low coupling modules. So in the ideal state we only need to complete their own part of the core business logic code, other aspects of dependence can be directly loaded by the person has been written to use the module.

First, AMD

AMD has only one interface: define (id?,dependencies?,factory);

It wants to make all of the dependencies (DEP) when declaring the module, and also as a parameter to the factory, like this:

Copy Code code as follows:

define ([' Dep1 ', ' Dep2 '],function (DEP1,DEP2) {...});

If you have no dependencies, define a simple module, so here it is.

Define (function () {
  var exports = {};
  Exports.method = function () {...};
  return exports;
});

Here are define, wrapping things up, that node implementation how did not see the Define keyword, it also wants to wrap things up, in fact, only node implicit packaging.

Requirejs is the realization of the AMD specification

Second, CMD

Yuber wrote Seajs, is to follow his proposed CMD specification, slightly stronger than AMD, use up to feel more convenient

Three, AMD and CMD difference

CMD is equivalent to load on demand, the definition of a module does not need to immediately develop a dependent module, when the need for require on it, more convenient, and AMD on the contrary, the definition of modules need to develop a dependent module, and in the form of parameters to introduce factory

AMD Mode definition Module

define ([' Dep1 ', ' Dep2 '],function (DEP1,DEP2) {
  //internal only use the established module return
  function () {};
});

Cmd

Define (function (require,exports,module) {
 //here if you need a XX module, you can introduce
 var xx=require (' xx ');
};

SEAJS also has the use function to introduce all dependent modules first, such as

Seajs. Use mode
seajs.use ([' Dep1 ', ' Dep2 '],function (DEP1,DEP2) {
  //here Implement Transaction
});

Four, plug-in support

But there are two more popular JavaScript modularity systems in the world, one for Node implementation and one for AMD, Commonjs. Many libraries support both AMD and COMMONJS, but do not support CMD. There may be many CMD modules in the country, but they are not popular in the world.

Now compare fire react and peripheral class library, is directly using COMMONJS module system, using NPM Management module, using browserify packaging output module.
In the near future ES6 new modular standard, may have to follow the new standard, what AMD, CMD may not be how to use.

But at present, the front-end development does not use modular programming is really out of the, and the current modular programming, I still suggest using SEAJS, although many plug-ins need to append or modify a small block of code to support. But once again it can be reused and will not affect the support of other standards. Overall is more convenient and practical.

Explain the difference between AMD and CMD alone where exactly?

Read the above Amd,requirejs and CMD, Seajs simple introduction will feel a little vague, total feeling more similar. Because like Requirejs it is not just pure amd inherent ideas, it is also the idea of cmd norms, is only recommended AMD specifications, Seajs is the same.

Here is Yuber's explanation for the difference between AMD and CMD:

AMD is requirejs in the promotion process of the modular definition of the standardized output.

CMD is the normalized output of the module defined by SEAJS in the process of popularization.

Similar also has the COMMONJS modules/2.0 specification, is bravojs in the promotion process to the module definition standardized output also has many??

These specifications are intended for modular development of JavaScript, especially in the browser-side.

At present, the implementation of these specifications can achieve the end of the browser-side modular development.

Difference:

1. For dependent modules, AMD is ahead of schedule, CMD is delayed execution. However, Requirejs from 2.0, also changed to be able to delay the execution (different according to the writing, processing different). CMD advocates as lazy as possible.

2. CMD is highly reliant on proximity, AMD is highly reliant on the front end. Look at the code:

Cmd

Define (function (Require, exports, module) {
 var a = require ('. a ')
 a.dosomething ()
 //Here omit 100 lines
 var B = r Equire ('./b ')//Reliance can be written near the
 b.dosomething ()
 //...
})

AMD's default recommendation is

define (['. a ', './b '], function (A, B) {//dependent must be written at the beginning
 a.dosomething ()
 //Here omit 100 lines
 b.dosomething ()/
 //. .
})

Although AMD also supports the writing of CMD, but also supports the require as a dependency, but Requirejs's author by default is most like the above, but also the official document default module definition.

3. AMD's API default is one when multiple uses, CMD's API strictly distinguishes, the promotion responsibility is unitary. For example, AMD, require divided into global require and local require, are called require. CMD, there is no global require, but according to the completeness of the module system, provide seajs.use to achieve the load start of the module system.

In CMD, each API is simple and pure.

4. There are also some details of the differences, the specific definition of this specification is good, do not say more.