A brief analysis of AMD CMD CommonJS specification--summary of javascript modular loading learning experience_javascript skills

This is a summary of learning about javascript modular AMD, CMD, and CommonJS. It serves as a record for those who also have questions about the three methods. If there are any errors or deviations, I hope you can point them out. I would be very grateful.

The default readers of this article probably know the usage of require and seajs (AMD, CMD usage), so the usage syntax is not included.

1. Why it was born:

These three specifications are all born for modularized loading of JavaScript. They load certain modules when they are used or expected to be used, so that a large number of systems with huge and complex codes can be well organized. and management. Modularization makes it less confusing when we use and manage code, and it also facilitates the cooperation of multiple people.

2. Those norms:

(1) CommonJS is an organization interested in building a JavaScript ecosystem. There is an entire community dedicated to making JavaScript programs more portable and interchangeable, both on the server and in the browser.

a group with a goal of building up the JavaScript ecosystem for web servers, desktop and command line apps and in the browser.

A purpose-built set of JavaScript ecosystem web servers, in browsers and command line applications and on the desktop. (He said so on his own wiki)

This organization has formulated some specifications (you can go to their website http://www.commonjs.org/), including the CommonJS Modules/1.0 specification. This is what we usually call the commonjs specification.

“The CommonJS API will fill that gap by defining APIs that handle many common application needs, ultimately providing a standard library as rich as those of Python, Ruby and Java. ”--(from http://www.commonjs. org/)

So Commonjs is a more server-side specification. Node.js adopts this specification. According to the CommonJS specification, a single file is a module. Loading the module uses the require method, which reads a file and executes it, and finally returns the exports object inside the file.

He also said that it can be used in the following scenarios, so he is more obviously biased towards the server side. Of course, you can also use it in the browser (they say you can).

•Server-side JavaScript applications
•Command line tools
•Desktop GUI-based applications
•Hybrid applications (Titanium, Adobe AIR)

(2), AMD specifications

Commonjs solves the problem of modularization and can be used in browsers. However, Commonjs loads modules synchronously. When the module is used, it is loaded and used. This synchronization mechanism causes problems in browsers. Well, loading speed and so on (synchronous loading of modules by the browser will cause problems such as performance, availability, debugging, and cross-domain access).

In view of the special situation of browsers, another specification has emerged. This specification can load dependent modules asynchronously and load them in advance. That is the AMD specification. AMD can be used as a drop-in version of CommonJS modules as long as CommonJS is not used for synchronous require calls. CommonJS code that uses synchronous require calls can be converted to use the callback-style AMD module loader (https://github.com/amdjs/amdjs-api/wiki/AMD-(%E4%B8%AD%E6%96% 87%E7%89%88) (it says).

Here is a module definition using a simple CommonJS transform (it is a usage of amd specification):

Copy code The code is as follows:

define(function (require, exports, module) {
var a = require('a'),
           b = require('b');
exports.action = function () {};

});


Therefore, AMD and Commonjs are compatible. As long as the calling method is slightly changed, synchronous loading can be achieved (I very much suspect that AMD also added a shell based on commonjs, and then I did not find other Shenma instructions and support text. I found It must be added here).

If you look at the AMD specifications, you will find that AMD basically states the dependent modules in advance and then preloads these modules. In fact, this requires you to think about these dependencies in advance and write them in advance, otherwise you have to go back to the process of writing code. Continue adding dependencies at the beginning.

(3), CMD

I don’t know if it is to address this problem. Taobao’s Yubo Daniel created seajs and claimed that this specification follows the CMD specification, and then gave a link to this specification (you will find the word draft when you open it). Regarding this standard, Uncle Yu said this on Zhihu

" AMD is the standardized output of module definitions during the promotion process of RequireJS.

CMD is the standardized output of module definition during the promotion process of SeaJS.
Similar to the CommonJS Modules/2.0 specification, it is the standardized output of module definitions during the promotion process of BravoJS.
There are many more⋯⋯
"

So this specification was actually developed for the promotion of Seajs. So let's take a look at what's going on with SeaJS. Basically, you know this specification.

Similarly, Seajs also preloads dependencies. The JS and AMD specifications are the same in terms of preloading. The obvious difference is in the calling and declaration of dependencies. Both AMD and CMD use define and require, but the CMD standard tends to propose dependencies during use. That is, no matter where the code is written, you suddenly find that you need to depend on another module, then just use require to introduce it in the current code. The specification will We help you with preloading, and you can just write whatever you want. But the AMD standard requires you to write the dependency parameters in the header in advance (not written well? Go back and write it well). This is the most obvious difference.

3. Symbiosis

Since CommonJS is a server-side specification, the other two standards do not actually conflict.

AMD is used more abroad, and of course it is also used domestically. jQuery 1 and 7 versions have been used, and Dojo has been used since version 1.6, which has proven that it is awesome enough.

Of course there are many people using CMD, but they are basically concentrated in China. The official website of Seajs shows that a lot of awesome companies are using it (including iQiyi, Tencent Weibo, Alipay, Taobao, etc.) Go here and take a look http://seajs.org/docs/), there are probably countless small and unknown ones. After all, many companies require seajs skills when recruiting.

So the three specifications are currently very good (in fact, it is mainly because js has its own module loading mechanism. I don’t know what will happen after es6 comes out).

What should we do when we write a file that needs to be compatible with different loading specifications? Take a look at the following code.

(function (root, factory) { 
 
  if (typeof define === 'function' && define.amd) { 
 
    // AMD 
 
    define(['jquery', 'underscore'], factory); 
 
  } else if (typeof exports === 'object') { 
 
    // Node, CommonJS之类的 
 
    module.exports = factory(require('jquery'), require('underscore')); 
 
  } else { 
 
    // 浏览器全局变量(root 即 window) 
 
    root.returnExports = factory(root.jQuery, root._); 
 
  } 
 
}(this, function ($, _) { 
 
  // 方法 
 
  function a(){}; // 私有方法，因为它没被返回 (见下面) 
 
  function b(){}; // 公共方法，因为被返回了 
 
  function c(){}; // 公共方法，因为被返回了 
 
    
 
  // 暴露公共方法 
 
  return { 
 
    b: b, 
 
    c: c 
 
  } 
 
}));

This code is compatible with various loading specifications.

4. The difference between AMD and CMD

The following points were said by Uncle Yu on Zhihu.

1. For dependent modules, AMD is executed in advance and CMD is executed delayed. However, starting from RequireJS 2.0, it has also been changed to be able to delay execution (the processing method is different depending on the writing method). CMD recommends as lazy as possible.
2. CMD advocates dependence on the nearest location, while AMD advocates dependence on the front.

3. AMD's API defaults to one being used for multiple purposes, while CMD's API is strictly differentiated and advocates single responsibility. For example, in AMD, require is divided into global require and local require, both called require. In CMD, there is no global require. Instead, seajs.use is provided to load and start the module system based on the completeness of the module system. In CMD, every API is simple and pure.

4. There are still some detailed differences. Just look at the definition of this specification, so I won’t go into details.
(Okay~ I won’t say more about the fourth point...)

5. Some similarities between AMD and CMD

Both have define and require, and the calling method can actually add dependency parameters, which means that preloading dependent modules can be implemented by providing dependency parameters (but it is not recommended because Note: define with id and deps parameters Usage does not belong to the CMD specification, but to the Modules/Transport specification ---From: https://github.com/seajs/seajs/issues/242).

AMD can also use require in the factory to load the used module now, but this module will not be loaded in advance, and it is a synchronous load that is loaded only when used.

var a = require('a'); // Load module a

If there is anything wrong, please correct me.

The above article briefly analyzes the AMD CMD CommonJS specification - a summary of the learning experience of javascript modular loading is all the content shared by the editor. I hope it can give you a reference, and I hope you will support Script Home.