JavaScript模块化 之( Commonjs、AMD、CMD、ES6 modules)演变史

经常在工作中使用define(['./modulename'],function(modulename){}),require(['modulename'],function(modulename){}),module.exports=modulename,import modulename from './modulename',export default function(){}这些模块但却很少去了解其由来，趁现在有点时间去看看

一、无模块化（春秋战国乱世争雄）

JavaScript最初的作用仅仅是验证表单，后来会添加一些动画，但是这些js代码很多在一个文件中就可以完成了，所以，我们只需要在html文件中添加一个script标签。

后来，随着前端复杂度提高，为了能够提高项目代码的可读性、可扩展性等，我们的js文件逐渐多了起来，不再是一个js文件就可以解决的了，而是把每一个js文件当做一个模块。那么，这时的js引入方式是怎样的呢？大概是下面这样：

   <script src="jquery.js"></script>
　　<script src="jquery_scroller.js"></script>
　　<script src="main.js"></script>
　　<script src="other1.js"></script>
　　<script src="other2.js"></script>
　　<script src="other3.js"></script>

即简单的将所有的js文件统统放在一起。但是这些文件的顺序还不能出错，比如jquery需要先引入，才能引入jquery插件，才能在其他的文件中使用jquery。

• 优点
  相比于使用一个js文件，这种多个js文件实现最简单的模块化的思想是进步的。
• 缺点
  污染全局作用域。 因为每一个模块都是暴露在全局的，简单的使用，会导致全局变量命名冲突，当然，我们也可以使用命名空间的方式来解决。
  对于大型项目，各种js很多，开发人员必须手动解决模块和代码库的依赖关系，后期维护成本较高。
  依赖关系不明显，不利于维护。 比如main.js需要使用jquery，但是，从上面的文件中，我们是看不出来的，如果jquery忘记了，那么就会报错。

所谓乱世出英雄，历经了多年征战，慢慢催生出了一帮帮英雄豪杰（CommonJS —> AMD —> CMD）

• 共同点

1. 都是使用字符串命名方式，让模块作用域只存在于当前模块作用域内，解决了命名空间的问题，且遵循一个模块代表一个文件的理念，将一个js系统地“分割“成多个模块，实现模块化系统。
2. AMD和CMD都是向着CommonJS致敬的，都有CommonJS的身影。

• 不同点

1. CommonJS起初为了解决，服务端的代码，把代码全都挤在一个文件内，从而导致文件复杂臃肿的，浏览器加载
   该JS文件，产生卡死；全局作用域污染等问题，而应运而生的模块化开发理念。而且其加载模块的方式属于同步的，
   需要遵循“先加载，停顿，再执行“的顺序来执行代码，因此很受网速限制。

2. AMD规范，虽然延续了CommonJS的理念，模块化开发，但不同的是，AMD遵循的是异步加载模块的规范。其加载依赖模块方式是属于依赖前置，即先加载需要的依赖模块，再执行回调函数，大大提高了效率。

3. CMD规范，是由国内前端大神，玉伯，编写的一个js库 — sea.js，在推过过程，提出的一个基于CommonJS的新
   规范—CMD。该规范与AMD类似，写法也类似。但不同的是，CMD遵循着依赖后置的理念。即AMD是一次性加载完

该模块所需要的所有模块，再执行回调。而CMD是按需加载，即需要用到的时候，才去加载对应模块。

4. 虽说AMD和CMD代表分别是requireJS和seaJS，但要清楚一点，前面2个是规范，后面2个是库，只是模块加载器。

二、commonJS规范

CommonJS就是一个JavaScript模块化的规范，该规范最初是用在服务器端的node的，前端的webpack也是对CommonJS原生支持的。

根据这个规范，每一个文件就是一个模块，其内部定义的变量是属于这个模块的，不会对外暴露，也就是说不会污染全局变量。

CommonJS的核心思想就是通过 require 方法来同步加载所要依赖的其他模块，然后通过 exports 或者 module.exports 来导出需要暴露的接口。如下所示：

// a.js
var x = 5;
var addX = function (value) {
  return value + x;
};
module.exports.x = x;
module.exports.addX = addX;

这里的a.js就是一个CommonJS规范的模块了。 这里的module就代表了这个模块，module的exports属性就是对外暴露

的接口，可以对外导出外部可以访问的变量，比如这里的x和addX。

exports 是对 module.exports 的引用。比如我们可以认为在一个模块的顶部有这句代码：

exports = module.exports

所以，我们不能直接给exports赋值，比如number、function等。

然后我们就可以在其他模块中引入这个模块使用了：

vara = require('./a.js');
console.log(example.x); // 5
console.log(example.addX(1)); // 6

这里的require就会获取到a.js所暴露的module.exports变量，然后就可以使用其暴露的x和addX了。

• 优点

1. 模块化，遵循一个模块一个文件的原则。

2. 耦合低，不容易导致全局变量的污染，因为每个模块都相当于闭包，都存在于自己的命名空间模块内的作用域。因此，外部无法访问内部私有变量。

3. 单一原则。每个模块内部都包含一个自执行函数，而这里提供2个变量，一个exports,一个module，但是最后输出的值，是在module.exports。

4. 统一性，都使用module.exorts或exports来导出模块，然后使用require()函数来导入模块（同步）。

5. 高度复用，可以将别人的项目内某个功能之间导入使用。（前提是用module.exports或exports导出）。

其实commonJS用于nodejs场景最多，也得利于node的兴起而广为人知

• 缺点

1. 不兼容浏览器，不能直接使用。因为浏览器不支持global，module，require，exports这四个全局变量。

2. 因为期初CommonJS的出现是应用在服务端，而且它的加载方式属于同步的，注意，是加载时是同步的。因此，编码时必须先去加载模块，再执行，这样会影响后面的代码的执行时间，形成阻塞。

三、AMD规范

官方对于AMD 的介绍

The Asynchronous Module Definition (AMD) API specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded. This is particularly well suited for the browser environment where synchronous loading of modules incurs performance, usability, debugging, and cross-domain access problems.

之前提到: CommonJS规范加载模块是同步的，也就是说，只有加载完成，才能执行后面的操作。AMD规范则是非同

步加载模块，允许指定回调函数。由于Node.js主要用于服务器编程，模块文件一般都已经存在于本地硬盘，所以加载

起来比较快，不用考虑非同步加载的方式，所以CommonJS规范比较适用。但是，如果是浏览器环境，要从服务器端

加载模块，这时就必须采用非同步模式，因此浏览器端一般采用AMD规范。而AMD规范的实现，就是大名鼎鼎的

require.js了。

AMD标准中，定义了下面两个API：

  1.require([module], callback)

   2. define(id, [depends], callback)

即通过define来定义一个模块，然后使用require来加载一个模块。 并且，require还支持CommonJS的模块导出方式。

定义alert模块：

define(function () {
    var alertName = function (str) {
      alert("I am " + str);
    }
    var alertAge = function (num) {
      alert("I am " + num + " years old");
    }
    return {
      alertName: alertName,
      alertAge: alertAge
    };
  });

引入模块：

require(['alert'], function (alert) {
  alert.alertName('JohnZhu');
  alert.alertAge(21);
});

但是，在使用require.js的时候，我们必须要提前加载所有的依赖，然后才可以使用，而不是需要使用时再加载。

• 优点

1. 模块化，遵循CommonJS理念，一个文件即模块。

2. 低耦合，由于采用命名空间内作用域有效，所有外部无法访问私有变量。

3. 统一性，都由全局变量define函数（导出）定义模块，全局变量require函数导入模块。

4. 高效性，由于采用的是异步加载的方式来加载模块，加载方法和CommonJS “一样“，都是使用require来加载模块。

但是AMD的require有点不一样，AMD的require导入模块时是异步的，而且语法是：require([依赖1,依赖2…],function()

{})。也就是说，要先加载完所有依赖，才执行回调函数，而该回调回调函数的参数，也必须严格按照数组内的模块顺

序来作为参数，回调函数内都是依赖于这些模块的逻辑代码。那些和这些依赖无关的，可以写在外面，在加载依赖

时，是不会影响接下来的代码的。这也就对应了：异步加载，是不会影响后面的代码的运行的。

• 缺点
  关系前置，我个人称为 “依赖前置“ 。可能由于设计思想的原因，AMD虽说是异步加载模块，并且不能按需加载，而是必须提前加载所有的依赖，再执行回调。

四、 CMD规范

CMD规范是阿里的玉伯提出来的，实现js库为sea.js。 它和requirejs非常类似，即一个js文件就是一个模块，但是CMD的加载方式更加优秀，是通过按需加载的方式，而不是必须在模块开始就加载所有的依赖。如下：

define(function(require, exports, module) {
  var $ = require('jquery');
  var Spinning = require('./spinning');
  exports.doSomething = ...
  module.exports = ...
})

• 优点
  同样实现了浏览器端的模块化加载。
  可以按需加载，依赖就近。

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

其实，这时我们就可以看出AMD和CMD的区别了，前者是对于依赖的模块提前执行，而后者是延迟执行。 前者推崇依赖前置，而后者推崇依赖就近，即只在需要用到某个模块的时候再require。 如下：

// AMD
define(['./a', './b'], function(a, b) {  // 依赖必须一开始就写好  
   a.doSomething()    
   // 此处略去 100 行    
   b.doSomething()    
   ...
});
// CMD
define(function(require, exports, module) {
   var a = require('./a')   
   a.doSomething()   
   // 此处略去 100 行   
   var b = require('./b') 
   // 依赖可以就近书写   
   b.doSomething()
   // ... 
});

五、ES6模块化（秦国一统六国）

之前的几种模块化方案都是前端社区自己实现的，只是得到了大家的认可和广泛使用，而ES6的模块化方案是真正的规范。 在ES6中，我们可以使用 import 关键字引入模块，通过 export 关键字导出模块，功能较之于前几个方案更为强大，也是我们所推崇的，但是由于ES6目前无法在浏览器中执行，所以，我们只能通过babel将不被支持的import编译为当前受到广泛支持的 require。

虽然目前import和require的区别不大，但是还是推荐使用使用es6，因为未来es6必定是主流，对于代码的迁移成本还是非常容易的。 如：

 import store from '../store/index'
  import {mapState, mapMutations, mapActions} from 'vuex'
  import axios from '../assets/js/request'
  import util from '../utils/js/util.js'

  export default {
    created () {
      this.getClassify(); 

      this.RESET_VALUE();
      console.log('created' ,new Date().getTime());

    }