JavaScript温故之AMD/CMD/UMD/CommonJS/ES6Module

当 Brendan Eich 设计 JavaScript 的第一个版本时，他可能不知道他的这个设计在过去二十年中将如何发展。目前已经有三种主要版本的语言规范（ES3 ES5 ES6），而其改进工作仍在继续。

说实话，JavaScript 从来就不是一个完美的编程语言。JavaScript 的弱点之一就是模块化的缺失。确实，将所有脚本语言仅用于页面上动画或表单验证，一切都可以在相同的全局范围内交互，在一开始确实不怎么需要模块化。

但是随着时间的推移，JavaScript 已经转变为通用语言，因为它开始用于在各种环境（浏览器、移动设备、服务器、物联网等）中构建复杂的应用程序。程序组件通过全局范围进行交互的旧方法变得不可靠，因为越来越多的代码往往会使应用程序过于脆弱，而能解决以上问题的关键在于模块化。

那么模块化具体解决了什么问题呢？简单的来说：

• 命名冲突
• 文件依赖
• 代码复用
• 多人协作
• 单元测试
• 性能提升
• …

为了实现 JavaScript 模块化。从 ES3 时代开始，就有前端工程师进行了探索，从最开始的函数模块，到后来的命名空间，再到后来的使用立即执行函数（Immediately-Invoked Function Expression，IIFE）。但是到此，只是解决了命名冲突、不污染全局变量等部分问题。对于模块间的相互依赖即引入顺序并没有很好的解决，虽然也出现了如 放大模式 和 宽放大模式 的操作方式，但是社区中并没有统一的解决方案。

CommonJS

2009年，Nodejs 的出现标志着 javascript 从此可以用于服务器端编程。同时标志 Javascript 模块化编程正式诞生。因为在当时的浏览器环境下，没有模块也不是特别大的问题，毕竟网页程序的复杂性有限。但是在服务器端，一定要有模块，与操作系统和其他应用程序互动，否则根本没法编程。

node.js的 模块系统，就是参照 CommonJS 规范实现的。在 CommonJS 中，有一个全局性方法 require，用于加载模块。假定有一个数学模块math.js，就可以像下面这样加载使用：

var math = require('math');
math.add(2,3); // 5

暴露模块也只需要：

module.export = {
    add(a, b) {
        return a + b;
    }
}

CommonJS 实现了 JavaScript 模块化。很自然地，人们就想要在浏览器上也实现相应的功能。由于一个重大的局限，使得 CommonJS 规范不适用于浏览器环境。

还是上面的代码，在 Nodejs 中，require math.js 只需要从项目文件夹读取就好，简单的来说，就是我们只需要等待 math.js 从硬盘读取的时间就好。

但是在浏览器环境下，math.js 通常存储在服务器。等待时间取决于网速的快慢，可能要等很长时间，会使得浏览器处于”假死”状态。

因此，浏览器端的模块，不能采用”同步加载”（synchronous），只能采用”异步加载”（asynchronous）。这就是AMD规范诞生的背景。

AMD

AMD 是 Asynchronous Module Definition 的缩写，意思就是”异步模块定义”。它采用异步方式加载模块，模块的加载不影响它后面语句的运行。所有依赖这个模块的语句，都定义在一个回调函数中，等到加载完成之后，这个回调函数才会运行。

实际上，AMD 是 RequireJS 在推广过程中对模块定义的规范化的产出。

主要解决了两个问题：

• 多个js文件可能有依赖关系，被依赖的文件需要早于依赖它的文件加载到浏览器
• js加载的时候浏览器会停止页面渲染，加载文件越多，页面失去响应时间越长

AMD 也采用 require() 语句加载模块，但是不同于CommonJS，它要求两个参数，还是上面那个例子：

require(['math'], function (math) {
    math.add(2, 3);
});

暴露模块也只需要：

define(function () {
    function add(a, b) {
        return a + b
    }
    return {
        add: add
    };
});

math.add() 与 math 模块加载不是同步的，浏览器不会发生假死。所以很显然，AMD比较适合浏览器环境。

而解决模块相互依赖引用问题。require.js 通过分析 define 中的配置，会将各个模块所以来的模块通过 callback 的参数传递进去。下面定义一个要被别的模块依赖的公共模块：

define('math', function () {
    function add(a, b) {
        return a + b
    }
    return {
        add: add
    };
});

其他模块使用时，只需要：

define('other', ['math'],function (math) {
    console.log(math.add(1, 2))
});

关于 require.js 的详细使用方法，这里不再展开，有兴趣的可以去了解。讲真的，作为一名脚手架工程了，在 SPA 大行其道的时代，我在工作中从未使用过 require.js 。只是在研究 IIFE 时，有文章提到 AMD/CMD 就是基于 IIFE ，只是将其扩展为的更为强大便利，我对此感觉十分感兴趣，故此才来研究一下。

CMD

CMD 即 Common Module Definition 通用模块定义。CMD 规范是国内发展出来的，就像AMD 有个 requireJS。CMD 有个浏览器的实现 SeaJS。SeaJS 要解决的问题和 requireJS 一样。只不过在模块定义方式和模块加载（可以说运行、解析）时机上有所不同。

和 AMD 采用 require()不同，CMD 使用 use 方法：

seajs.use(['math.js'],function(math){
    console.log(math.add(1, 2))
});

但是实际上 CMD 中也有 require 方法。用在 define 定义模块中：

// math.js
define(function(require, exports, module) {
    exports.add = function(a, b) {
        return a + b;
    };
});

这里定义了一个模块，define 接受的参数中有 require。但是只有在需要调用其他模块时，才能用到：

// other.js
define(function(require, exports, module) {
    console.log(require('math').add(1, 2))
});

进行到这里，虽然 CMD 的用法和 AMD 不仅相同。但是能够明显的感觉到他们做的事情是一样的。

虽然实现的过程不尽相同，理念也不同。但是这并不妨碍他们都已经过时的事实。

从语法上来看，CMD 更接近 CommonJS。甚至连 exports => module.exports 都和 CommonJS。但是实际上无论是 AMD 和 CMD ，在插件和工具的加持下，都可以运行到 Node 端，关于插件和Node这里不展开，有兴趣的同学可以研究下。

AMD&CMD

AMD 与 CMD 最明显的区别就是在模块定义时对依赖的处理不同。

AMD推崇依赖前置，在定义模块的时候就要声明其依赖的模块。

CMD推崇就近依赖，只有在用到某个模块的时候再去require。

看到很多网站说AMD是异步加载，CMD是同步加载，肯定是不准确的，他们都是异步加载模块。

通俗来说：

AMD在加载完成定义（define）好的模块就会立即执行，所有执行完成后，遇到require才会执行主逻辑。（提前加载）

CMD在加载完成定义（define）好的模块，仅仅是下载不执行，在遇到require才会执行对应的模块。（按需加载）

AMD用户体验好，因为没有延迟，CMD性能好，因为只有用户需要的时候才执行。

CMD为什么会出现，因为对 node.js 的书写者友好，因为符合写法习惯，就像为何vue会受人欢迎的一个道理。

UMD

是一种规范，就是一种兼容 CommonJS/AMD/CMD 的兼容写法。它是为了让模块同时兼容CommonJS/AMD/CMD 规范而出现的，多被一些需要同时支持浏览器端和服务端引用的第三方库所使用。通过 define.amd/define.cmd/module 等判断当前支持什么方式，都不行就挂载到 window 全局对象上面去。

UMD是一个时代的产物，当各种环境最终实现 ES harmony 的统一的规范后，它也将退出历史舞台。

(function (root, factory) {
    if (typeof define === 'function' && (define.amd || define.cmd)) {
        //AMD,CMD
        define(['b'], function(b){
          return (root.returnExportsGlobal = factory(b))
        });
    } else if (typeof module === 'object' && module.exports) {
        //Node, CommonJS之类的
        module.exports = factory(require('b'));
    } else {
        //公开暴露给全局对象
        root.returnExports = factory(root.b);
    }
}(this, function (b) {
  return {};
}));

ES6Module

ES6 在语言标准的层面上，实现了模块功能，而且实现得相当简单，完全可以取代 CommonJS/AMD/CMD 规范，成为浏览器和服务器通用的模块解决方案。

ES6 模块的设计思想是尽量的静态化，使得编译时就能确定模块的依赖关系，以及输入和输出的变量。CommonJS 和 AMD 模块，都只能在运行时确定这些东西。比如，CommonJS 模块就是对象，输入时必须查找对象属性。

// CommonJS模块
let { stat, exists, readfile } = require('fs');

// 等同于
let _fs = require('fs');
let stat = _fs.stat;
let exists = _fs.exists;
let readfile = _fs.readfile;

上面代码的实质是整体加载fs模块（即加载fs的所有方法），生成一个对象（_fs），然后再从这个对象上面读取 3 个方法。这种加载称为“运行时加载”，因为只有运行时才能得到这个对象，导致完全没办法在编译时做“静态优化”。

ES6 模块不是对象，而是通过export命令显式指定输出的代码，再通过import命令输入。

// ES6模块
import { stat, exists, readFile } from 'fs';

上面代码的实质是从fs模块加载 3 个方法，其他方法不加载。这种加载称为“编译时加载”或者静态加载，即 ES6 可以在编译时就完成模块加载，效率要比 CommonJS 模块的加载方式高。当然，这也导致了没法引用 ES6 模块本身，因为它不是对象。

由于 ES6 模块是编译时加载，使得静态分析成为可能。有了它，就能进一步拓宽 JavaScript 的语法，比如引入宏（macro）和类型检验（type system）这些只能靠静态分析实现的功能。

除了静态加载带来的各种好处，ES6 模块还有以下好处。

• 不再需要UMD模块格式了，将来服务器和浏览器都会支持 ES6 模块格式。目前，通过各种工具库，其实已经做到了这一点。
• 将来浏览器的新 API 就能用模块格式提供，不再必须做成全局变量或者navigator对象的属性。
• 不再需要对象作为命名空间（比如Math对象），未来这些功能可以通过模块提供。

虽然 ES6 引入了 Module 从语法层面实现了模块化。但是，实际上市面上大部分浏览器都尚未支持。我们在 cli 中打包后生成的代码其实也就是打包成了 AMD 的样子。

好在 Nodejs 已经支持 ESModule。几大主流浏览器都在积极推进支持原生 ES6 Modules 的工作，部分浏览器的技术预览版也已经初步完成了这一使命。可以通过 http://caniuse.com 查看目前浏览器的支持情况。

相信在不远的将来，JavaScript 终能摆脱模块化这段不堪回首的过去。

文章来源：https://zhuanlan.zhihu.com/p/165598502。如有侵权，请联系删除

模块化