目前可以考量到的模块标准有3种：

AMD和CommonJS，以及JavaScript下一个版本Harmony

当前只需考虑AMD和CommonJS2种模式

AMD:在浏览器中编写模块化的javascript的格式，异步模块定义，Asynchronous Module Definition，目标是为现在的开发者提供一个可用的模块化JavaScript的解决方案

CommonJS：为服务器端优化的模块格式，在服务器端声明模块指定了一个简单的API，视图覆盖IO/文件系统，promise模式等，是以模块及程序包的标准进行设计，Node.js也是基于该标准的设计

2者的区别很明显

为什么 AMD 对于编写模块化 JavaScript 是一个更好的选择？

• 为如何定义高灵活性的模块提供了一个清晰的方案。
• 相对目前我们很多人使用的全局命名空间加注入 <script> 标签的解决方案来说，要简洁得多。它有一个简洁的方式来声明独立的模块以及他们可能包含的依赖项。
• 模块定义都被封装了起来，帮我们避免了全局命名空间的污染。
• 比其它替代方案（例如 CommonJS，我们马上会讨论到）效果更好。没有跨域、本地或调试带来的问题，也不依赖于服务器端工具。大多数 AMD 加载器都支持在浏览器中加载模块，而不须要一个构建的过程。
• 提供了一个“传输”方法来用在单个文件中包含多个模块。其它例如 CommonJS 这样的方式都尚没有对传输格式达成共识。
• 当需要时可以进行延迟加载。

不得不提：CommonJS更像是一个通用规范，在服务器端也使用的规范，无疑是JSer更好的选择

在国内发展出来了CMD，我理解为在RequireJS的基础上兼容CommonJS的方案

区别简单说明：

• AMD:提前执行（异步加载：依赖先执行）+延迟执行
• CMD:延迟执行（运行到需加载，根据顺序执行）

• AMD:依赖前置，在函数wrap之前设定好依赖关系
• CMD:依赖就近，在代码块中，需要的地方定义加载

这点

这点个人感觉只是书写风格上的额差异，对实际开发中的影响忽略不计：就好比php（CMD）和java（AMD）一样（举例不恰当，但代码风格至少如此）

• AMD:API根据使用范围有区别，但使用同一个api接口
• CMD:每个API的职责单一

这点其实也不影响实际的开发，依旧是代码风格

分析：

所以最主要的区别就是执行顺序

如果将模块定义都允许先加载，保证不会因为执行顺序产生问题（面向对象的开发方式），则CMD的使用方式更为灵活

依赖前置和依赖就近，则可以规范到所有依赖关系预先定义，也就是依赖前置（对于软依赖，也就是不确定的依赖关系，可以使用依赖就近的加载模式）

也就是说CMD可以选择性的处理依赖关系，更加灵活

API当然是职责单一的模式不容易在开发中产生一些不可预计的错误

根据以上3点的分析，其实CMD的模式无疑也非常适合浏览器端的使用

再说一个最主要的：

AMD的一个优点，暂时CommonJS无法实现，也就是异步并行加载，在AMD的规范下，同时异步加载是不会产生错误的，但CMD的机制则不同，这种加载方式会产生错误，如果能规范化模块内容形式，也可以（以上问题需要浏览器的同步并行加载支持）

目前sea.js是基于CMD规范的浏览器端加载器

下面对sea.js调用js插件作为使用例子：

jquery1.7以上版本会自动模块化，支持AMD模式：主要是使用define函数，sea.js虽然是CommonJS规范，但却使用了define来定义模块

所以jQuery已经自动模块化了

seajs.config({
'base':'/',
'alias':{
    'jquery':'jquery.js'//定义jQuery文件
}
});

use函数和AMD的require类似，主要用来在顶层 JavaScript 文件中或须要动态读取依赖时加载代码

seajs.use(['jquery'],function($){
//$为jquery对象
});

define函数和AMD的define类似

define(function(require, exports, module{
     //先要载入jQuery的模块
     var $ = require('jquery');
     //然后将jQuery对象传给插件模块
     require('./cookie')($);
     //开始使用 $.cookie方法
});