标签：export   seajs   stat   temp   llb   获得   head   call   特殊   

1.名词解释
AMD：Asynchronous Modules Definition异步模块定义，提供定义模块及异步加载该模块依赖的机制。
CMD：Common Module Definition 通用模块定义，提供模块定义及按需执行模块

RequireJS 遵循 AMD（异步模块定义）规范，Sea.js 遵循 CMD （通用模块定义）规范。规范的不同，导致了两者 API 不同。

2. 提前执行：提前异步并行加载
优点：尽早执行依赖可以尽早发现错误；缺点：容易产生浪费
3. 延迟执行：延迟按需加载
优点：减少资源浪费 缺点：等待时间长、出错时间延后

2.1 AMD与CMD代码模式

AMD代码模式-运行策略

define([‘./a‘, ‘./b‘], function(a, b) { //运行至此，a.js和b.js已经下载完成 a模块和b模块已经执行完，直接可用；
    a.doing();
    // 此处省略500行代码
    b.doing();
});

CMD代码模式-运行策略

define(function(require, exports, module) {
     var a = require("./a"); //等待a.js下载、执行完
     a.doing();
     // 此处省略500行代码
     var b = require("./b"); //依赖就近书写
     b.doing();
});

3. AMD 的 API 默认是一个当多个用，CMD 的 API 严格区分，推崇职责单一。比如 AMD 里，require 分全局 require 和局部 require，都叫 require。CMD 里，没有全局 require，而是根据模块系统的完备性，提供 seajs.use 来实现模块系统的加载启动。CMD 里，每个 API 都简单纯粹。

方案 | 优势 | 劣势 | 特点
AMD | 速度快 | 会浪费资源 | 预先加载所有的依赖，直到使用的时候才执行
CMD | 只有真正需要才加载依赖 | 性能较差 | 直到使用的时候才定义依赖

它们除了希望放在浏览器作为loader也能够放在服务端，提供加载功能。在我看来，AMD擅长在浏览器端、CMD擅长在服务器端。这是因为浏览器加载一个功能不像服务器那么快，有大量的网络消耗。所以一个异步loader是更接地气的。

或者，干脆使用YUI3的模块机制，在上线前进行压制。把互相依赖的模块压在一个文件中。

---------------------------------------------------------------------------------------------------

每一个卓越的思想都有一份朴实的代码实现。所以无论AMD与CMD都要面临以下几个问题：

scriptElement= document.createElement(‘script‘);
scriptElement.src = moduleUrl;
scriptElement.async = true;
scriptElement.onload = function(){.........};
document.head.appendChild(scriptElement);

  AMD规范定义了一个自由变量或者说是全局变量 define 的函数

define( id?, dependencies?, factory );    

CommonJS
这种方式通过一个叫做require的方法，同步加载依赖，然后返导出API供其它模块使用，一个模块可以通过exports或者module.exports导出API。CommonJS规范中，一个单独的文件就是一个模块。每一个模块都是一个单独的作用域，在一个文件中定义的变量，都是私有的，对其他文件是不可见的。
Well
服务端模块可以很好的复用
这种风格的模块已经很多了，比如npm上基本上都是这种风格的module
简单易用
Less Well
加载模块是同步的，所以只有加载完成才能执行后面的操作
多个模块不能并行加载
像Node.js主要用于服务器的编程，加载的模块文件一般都已经存在本地硬盘，所以加载起来比较快，不用考虑异步加载的方式，所以CommonJS规范比较适用。但如果是浏览器环境，要从服务器加载模块，这是就必须采用异步模式。所以就有了 AMD 、CMD 的解决方案。

 

 

CommonJS规范

 CommonJS是在浏览器环境之外构建JavaScript生态系统为目标产生的项目，比如服务器和桌面环境中。CommonJS规范是为了解决JavaScript的作用域问题而定义的模块形式，

可以使每个模块在它自身的命名空间中执行。该规范的主要内容是：模块必须通过  module.exports导出对外的变量或接口，通过require()来导入其他模块的输出到当前模块。

例子：

[javascript] view plain copy

 

 

 

 

1. // moduleA.js  
2. module.exports = function( value ){  
3.     return value * 2;  
4. }  

[javascript] view plain copy

 

 

 

 

1. // moduleB.js  
2. var multiplyBy2 = require(‘./moduleA‘);  
3. var result = multiplyBy2(4);  

CommonJS是同步加载模块，但其实也有浏览器端的实现，其原理是将所有模块都定义好并通过id进行索引，这样就可以浏览器进行解析了
 服务器端的Node.js遵循CommonJS规范。核心思想是允许模块通过require 方法来同步加载所要依赖的其他模块，然后通过 exports或module.exports来导出需要暴露的接口。

[javascript] view plain copy

 

 

 

 

1. require("module");  
2. require("../file.js");  
3. exports.doStuff = function() {};  
4. module.exports = someValue;  

优点：

•  服务器端便于重用
• NPM中已经将近20w个模块包
• 简单并容易使用

缺点：

• 同步的模块方式不适合不适合在浏览器环境中，同步意味着阻塞加载，浏览器资源是异步加载的
• 不能非阻塞的并行加载多个模块

AMD

AMD规范其实只有一个主要接口 define(id,dependencies,factory)，它要在声明模块的时候指定所有的依赖dependencies，并且还要当做形参传到factory中，对于依赖的模块提前执行，依赖前置

[javascript] view plain copy

 

 

 

 

1. define("module", ["dep1", "dep2"], function(d1, d2) {  
2.   return someExportedValue;  
3. });  
4. require(["module", "../file"], function(module, file) { /* ... */ });  

优点：

• 适合在浏览器环境异步加载
• 并行加载多个模块

缺点：

• 提高开发成本，代码阅读和书写比较困难
• 不符合通用的模块思维方式，是一种妥协的实现

CMD

CMD规范和AMD相似，尽量保持简单，并且与CommonJS和NodeJS的Modules规范保持了很大的兼容性。

[javascript] view plain copy

 

 

 

 

1. define(function(require, exports, module) {  
2.   var $ = require(‘jquery‘);  
3.   var Spinning = require(‘./spinning‘);  
4.   exports.doSomething = ...  
5.   module.exports = ...  
6. })  

优点：

• 依赖就近，延迟执行
• 很容易在node中运行

缺点：

• 依赖SPM打包，模块的加载逻辑偏重

AMD、CMD和Common规范

标签：export   seajs   stat   temp   llb   获得   head   call   特殊   

原文地址：https://www.cnblogs.com/gopark/p/10142060.html