初探前端模块化规范（AMD,CommonJS,UMD,CMD）
以前，开发中我们通常使用整套框架（easyui，bootstrap）,不得不说，easyui的自定义打包下载，让我很困惑，因为那个时候，需要手动跟踪组件依赖，也就是说，你需要自己手动下载相关文件，并注意在页面的引入顺序（好吧，有点耐心，细致点，总能解决的）。
现在，项目规模的增长，业务复杂度的增加，以及客户对交互与ui的要求不断提高。我们基本不再使用整套框架，都是选择开源的单一组件，各种组合，来实现相关业务。我们需要引入大量的插件文件，页面引入时，如何避免组件的彼此冲突，相互干扰，成为了很尖锐的问题。（曾经被select.js重写$坑过的朋友应该有感触）。
为了解决这个问题，两种竞争关系的模块规范AMD和CommonJS问世了，它们允许开发者遵照一种约定的沙箱化和模块化的方式来写代码，这样就能避免“污染生态系统”。
一 AMD(Asynchronous Module Definition ) 异步模块加载--主要适用在web客户端
以require.js为主力，在社区推进规范发展。
下面是只依赖jquery的模块foo的代码：
// 文件名: foo.js
define(['jquery'], function ($) {
// 方法
function myFunc(){};
// 暴露公共方法
return myFunc;
});
还有稍微复杂点的例子，下面的代码依赖了多个组件并且暴露多个方法:
// 文件名: foo.js
define(['jquery', 'underscore'], function ($, _) {
// 方法
function a(){}; // 私有方法，因为没有被返回(见下面)
function b(){}; // 公共方法，因为被返回了
function c(){}; // 公共方法，因为被返回了
// 暴露公共方法
return {
b: b,
c: c
}
});
define为require.js向宿主环境注入的全局方法，用于模块的定义，它接受的第一个参数是一个依赖数组，标识当前模块的依赖。它接受的第二个参数是一个回调函数。只有当所有依赖都可用时，回调函数才会执行。
注意：
1、依赖组件和变量的顺序是一一对应的（例如，jquery->$, underscore->_）；
2、我们可以用任意的变量名来表示依赖组件。假如我们把$改成$$，在函数体里面的所有对jQuery的引用都由$变成了$$；
3、最重要的是你不能在回调函数外面引用变量$和_，因为它相对其它代码是独立的。这正是模块化的目的所在！
4、开发环境中，我们通常一个模块一个文件，这样方便管理，在生产环境中，为了性能，可以使用工具，对文件合并，减少请求。
二 Common JS-通用js模块化规范--适用于server端。
就像前面的格式一样，下面是用CommonJS规范实现的foo模块的写法：
// 文件名: foo.js
// 依赖
var $ = require('jquery');
// 方法
function myFunc(){};
// 暴露公共方法（一个）
module.exports = myFunc;
还有更复杂的例子，下面的代码依赖了多个组件并且暴露多个方法：
// 文件名: foo.js
var $ = require('jquery');
var _ = require('underscore');
// methods
function a(){}; // 私有方法，因为它没在module.exports中 (见下面)
function b(){}; // 公共方法，因为它在module.exports中定义了
function c(){}; // 公共方法，因为它在module.exports中定义了
// 暴露公共方法
module.exports = {
b: b,
c: c
};
注意：
1、这里的require方法用于引入模块，当前模块使用module.exports向外界暴露接口。
2、我们严格遵循一个模块对应一个文件。
虽然看起来已经很不错了，我们是不是还可以更进一步呢？有人希望建立一个与环境无关的通用模块规范，让client端和server端的js代码可以无缝切换使用。于是产生了兼容性方案UMD
三 UMD(通用模块规范)
不得不承认，这个模式略难看，但是它兼容了AMD和CommonJS，同时还支持老式的“全局”变量规范：
(function (root, factory) {
if (typeof define === 'function' && define.amd) {
// AMD
define(['jquery'], factory);
} else if (typeof exports === 'object') {
// Node, CommonJS之类的
module.exports = factory(require('jquery'));
} else {
// 浏览器全局变量(root 即 window)
root.returnExports = factory(root.jQuery);
}
}(this, function ($) {
// 方法
function myFunc(){};
// 暴露公共方法
return myFunc;
}));
保持跟上面例子一样的模式，下面是更复杂的例子，它依赖了多个组件并且暴露多个方法:
(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
}
}));
四 CMD
CMD是SeaJS 在推广过程中对模块定义的规范化产出
CMD和AMD的区别有以下几点：
1.对于依赖的模块AMD是提前执行，CMD是延迟执行。不过RequireJS从2.0开始，也改成可以延迟执行（根据写法不同，处理方式不通过）。
2.CMD推崇依赖就近，AMD推崇依赖前置。
举个例子：
//CMD
define(
function
(require, exports, module) {
//依赖可以就近书写
var $= require('jquery');
//通过exports向外暴露接口
exports.do=function(){
console.log($);
}
});
总结：
前端发展日新月异，每一项技术都有自己的使用场景与局限，虽然模块化规范看起来比较简单，模块化思维的建立才是最让人恼火的。同时，他们都对应着一系列的技术方案，从开发，测试，构建，打包，到性能优化。前端是一个越来越需要专业化的工作。
如何合理的设计，抽象模块，实施分割，封装，至于应用到实际生产中，真的是一件需要智慧，体力和勇气的事情啊
。
目前本人存在的问题：不能有效的运用于实践中，思维一时难以转变。
欢迎组队研究，探讨。如有错漏，请指正！
引用/参考：
1 [译]神马是AMD, CommonJS, UMD?
2 JavaSript模块化
3 AMD 规范 ，CMD规范 ，AMD 和 CMD 的区别有哪些？
4 关于 CommonJS AMD CMD UMD