对CommonJS、AMD、CMD简单粗暴的理解

　　对于大型Web应用或者项目，动辄上万行的代码，给开发和后期维护带来了不小的麻烦。所以，须要有一种规范化的模块管理机制，帮助开发者集中处理模块的定义与调用关系。

　　在ES6正式出台前，已经有很多人致力于推出适合Web开发的模块化管理标准，CommonJS、AMD和CMD就是其中的成功表明。

　　如下为我查阅资料后，对三者最直观的理解：

CommonJS

　　一般被应用于服务器，实现表明：NodeJS。NodeJS相信你们都不陌生，它的出现成功将Javascript应用到了服务器端，使得前段开发者也能较为省力得转向后端开发，而无需学习一门新语言。

　　在服务器端，模块的加载和执行都在本地完成，所以，CommonJS并不要求模块加载的异步化。

模块定义与加载

• 对于CommonJS，模块以文件为单位存在，模块实现所有位于该文件内部
• 在文件末尾，须要把将要导出的方法添加到module.exports对象上
• 随后在其余文件（模块）中，可使用require()方法加载须要的模块，该方法要求一个参数：能够是一个模块名（此时加载的是默认提供的模块），或者是一个URL。若是是URL，其能够是相对路径或绝对路径，或者是一个指定的路径（由Node自行解析并寻找）。关于文件的后缀名，默认为“.js”，所以参数中能够省略后缀名；而若是指定的模块未发现，则会继续寻找以“.json”和“.node”为后缀的文件（其中以“.node”为后缀的文件将会以编译后的二进制文件格式解析）。

AMD

　　AMD（异步模块加载）和CMD一般用于浏览器端，它们与CommonJS最明显的不一样就是异步加载。AMD的实现表明是require.js，它也是require.js在推广过程当中的附加产物。

模块定义与加载

• AMD模块不必定以文件为单位，小模块集群也是容许的；但基本上在开发过程当中，仍是应当以文件的形式进行管理
• 模块的定义由define()方法肯定，该方法接受两个参数：
  • 一是当前模块的依赖模块，以数组形式传递
  • 二是当前模块的实现，以回调形式传递。一中的依赖经过参数传给回调。在回调末尾，以对象的形式返回须要公开的方法组。
• 模块的配置使用require.config()方法，它接受一个对象类型的参数，该对象须要配置一些属性：baseUrl，paths，shim等
  • baseUrl：全部模块查找的根路径；未设置时默认是使用require.js的HTML文件所在目录。或者可使用data-main属性在加载require.js的标签中定义根路径。
  • callback：当前依赖所有加载完成后的回调函数
  • config：将Application级别的配置信息传递给模块时使用。传递时使用module.config()方法。

    requirejs.config({
    config: {
    'bar': {
    	size:'large'
    },
    'baz': {
    	color: 'blue'
            }
        }
    });
    //bar.js直接使用module模块
    define(function (require, exports, module) {
        var size = module.config().size;
    });
    //baz.js使用了一个依赖数组，并要求一个特殊的依赖“module”
    define(['module'], function(module) {
        var color = module.config().color;
    });

    当“some/newmodule”调用了“require('foo')”，它将获取到foo1.2.js文件；而当“some/oldmodule”调用“`require('foo')”时它将获取到foo1.0.js。

  • exports：模块的输出
  • init：模块的初始化工做
  • paths：模块文件的路径。当paths中以/开头、或以.js结尾、或包含协议时（如http://...），其路径不在根路径下。
  • shim：须要未用define()方法定义的模块时使用。值为一组模块对象，每一个对象分别有一些属性：deps，exports，init等。值得注意的是，shim只是定义了模块的依赖关系，仍然须要经过define+require的方式调用。
    • deps：模块的依赖数组
    • exports：模块的输出
  • map：对于给定的模块前缀，使用一个不一样的模块ID来加载该模块。可使用*号做为默认配置，且该配置能够被更具体的配置覆盖。

    requirejs.config({
    	map: {
    	    'some/newmodule': {
    	        'foo': 'foo1.2'
    	    },
    	    'some/oldmodule': {
    	        'foo': 'foo1.0'
    	    }
    	}
    });	

  • 更多参数请戳 参考连接

 CMD

　　CMD（通用模块加载）是sea.js在推广过程当中的产出，它与AMD主要有如下几点区别（来自seajs的官方阐述）：

• 定位有差别。RequireJS 想成为浏览器端的模块加载器，同时也想成为 Rhino / Node 等环境的模块加载器。Sea.js 则专一于 Web 浏览器端，同时经过 Node 扩展的方式能够很方便跑在 Node 环境中。
• 遵循的规范不一样。RequireJS 遵循 AMD（异步模块定义）规范，Sea.js 遵循 CMD （通用模块定义）规范。规范的不一样，致使了二者 API 不一样。Sea.js 更贴近 CommonJS Modules/1.1 和 Node Modules 规范。
• 推广理念有差别。RequireJS 在尝试让第三方类库修改自身来支持 RequireJS，目前只有少数社区采纳。Sea.js 不强推，采用自主封装的方式来“海纳百川”，目前已有较成熟的封装策略。
• 对开发调试的支持有差别。Sea.js 很是关注代码的开发调试，有 nocache、debug 等用于调试的插件。RequireJS 无这方面的明显支持。
• 插件机制不一样。RequireJS 采起的是在源码中预留接口的形式，插件类型比较单一。Sea.js 采起的是通用事件机制，插件类型更丰富。
• AMD提倡依赖前置，也就是在一开始就定义加载。而CMD则推崇依赖就近，即就在使用到模块的代码前面进行依赖加载。这里就须要注意了，使用requirejs会按照模块的依赖顺序进行加载，即模块不会按照代码里的顺序进行加载，可能形成意外地结果。

  这造成了两种大相径庭的加载方式：“预加载”和“懒加载”。AMD提早将全部模块的全部依赖加载完成后，才开始执行主流程；而CMD是遇到一个依赖开始加载，完成后执行当前流程，遇到下一个依赖再次去加载，而后再执行下一步。固然，同一模块的依赖之间仍然是异步加载的。

模块定义与加载

　　流程与AMD相似，再也不赘述，只简单介绍seajs的API。

• cache：查看当前模块系统中的模块信息
• config：配置模块参数，参数列表：
  • alias：模块别名
  • base：根路径
  • paths：模块文件所在路径
  • vars：变量配置。好比须要在运行时肯定模块路径的状况：

    seajs.config({
        // 变量配置
        vars: {
            'locale': 'zh-cn'
        }
    });
    define(function(require, exports, module) {
      var lang = require('./i18n/{locale}.js');
         //=> 加载的是 path/to/i18n/zh-cn.js
    });

    使用变量须要用花括号包围，如例中的{locale}。

• data：查看 seajs 全部配置以及一些内部变量的值，可用于插件开发。当加载遇到问题时，也可用于调试。
• resolve：利用模块系统的内部机制对传入的字符串参数进行路径解析。
• use：加载模块。seajs.use(id/url/urlArray, callback)