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规范

之前提到: 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());

    }