JavaScript——模块化的历史进程梳理

随着前端js代码复杂度的提高，js模块化是必然趋势，不仅好维护，同时依赖很明确，不会全局污染，今天整理一下模块化的几个规范吧~

首先梳理一下模块化的发展情况~

无模块化-->CommonJS规范-->AMD规范-->CMD规范-->ES6模块化

1. 无模块化

script标签引入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。缺点很明显：

污染全局作用域
维护成本高
依赖关系不明显

2. CommonJS规范

该规范最初是用在服务器端的node的，它有四个重要的环境变量为模块化的实现提供支持：module、exports、require、global。实际使用时，用module.exports定义当前模块对外输出的接口（不推荐直接用exports），用require加载模块（同步）。

// a-commonJs.js (导出)
var a = 5;var add = function(param){//在这里写上需要向外暴露的函数、变量    return a + param}module.exports.a = a;module.exports.add = add===========================
// b-commonJs.js引用自定义模块，参数包含路径，可省略.js（导入）
var addFn = require('./a-commonJs')console.log(addFn.add(3)) //8console.log(addFn.a) //5复制代码

一点说明：

exports 是对 module.exports 的引用。比如我们可以认为在一个模块的顶部有这句代码：   exports = module.exports所以，我们不能直接给exports赋值，比如number、function等。 复制代码

注意：因为module.exports本身就是一个对象，所以，我们在导出时可以使用

module.exports = {foo: 'bar'} //true

module.exports.foo = 'bar' //true。

但是, exports 是 module.exports 的一个引用，或者理解为exports是一个指针，exports指向module.exports，这样，我们就只能使用 exports.foo = 'bar' 的方式，而不能使用

exports = {foo: 'bar'} //error 这种方式是错误的，相当于重新定义了exports

一点优点：解决了依赖、全局变量污染的问题

一点缺点： CommonJS用同步的方式加载模块。在服务端，模块文件都存在本地磁盘，读取非常快，所以这样做不会有问题。但是在浏览器端，限于网络原因，CommonJS不适合浏览器端模块加载，更合理的方案是使用异步加载，比如下边AMD规范。

3. AMD规范

承接上文，AMD规范则是非同步加载模块，允许指定回调函数，AMD 是 RequireJS 在推广过程中对模块定义的规范化产出。。

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

require([module], callback)
define(id, [depends], callback)
require.config()

即通过define来定义一个模块，然后使用require来加载一个模块, 使用require.config()指定引用路径。

先到require.js官网下载最新版本,然后引入到页面，如下：

<script data-main="./alert" src="./require.js"></script>

data-main属性不能省略。

以上分别是定义模块，引用模块，运行在浏览器弹出提示信息。

引用模块的时候，我们将模块名放在[]中作为reqiure()的第一参数；如果我们定义的模块本身也依赖其他模块,那就需要将它们放在[]中作为define()的第一参数。

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

一点优点：适合在浏览器环境中异步加载模块、并行加载多个模块

一点缺点：不能按需加载、开发成本大

4. CMD

AMD 推崇依赖前置、提前执行，CMD推崇依赖就近、延迟执行。CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。

很明显，CMD是按需加载，就近原则。

5. ES6模块化

在ES6中，我们可以使用 import 关键字引入模块，通过 exprot 关键字导出模块，功能较之于前几个方案更为强大，也是我们所推崇的，但是由于ES6目前无法在浏览器中执行，所以，我们只能通过babel将不被支持的import编译为当前受到广泛支持的 require。

es6在导出的时候有一个默认导出，export default,使用它导出后，在import的时候，不需要加上{}，模块名字可以随意起。该名字实际上就是个对象，包含导出模块里面的函数或者变量。

但是一个模块只能有一个export default。

6. CommonJs和ES6区别

以下引用阮一峰老师的内容：

（1） CommonJS 模块输出的是一个值的拷贝，ES6 模块输出的是值的引用。

CommonJS 模块输出的是值的拷贝，也就是说，一旦输出一个值，模块内部的变化就影响不到这个值。
ES6 模块的运行机制与 CommonJS 不一样。JS 引擎对脚本静态分析的时候，遇到模块加载命令import，就会生成一个只读引用。等到脚本真正执行时，再根据这个只读引用，到被加载的那个模块里面去取值。换句话说，ES6 的import有点像 Unix 系统的“符号连接”，原始值变了，import加载的值也会跟着变。因此，ES6 模块是动态引用，并且不会缓存值，模块里面的变量绑定其所在的模块。

（2） CommonJS 模块是运行时加载，ES6 模块是编译时输出接口。

运行时加载: CommonJS 模块就是对象；即在输入时是先加载整个模块，生成一个对象，然后再从这个对象上面读取方法，这种加载称为“运行时加载”。
编译时加载: ES6 模块不是对象，而是通过 export 命令显式指定输出的代码，import时采用静态命令的形式。即在import时可以指定加载某个输出值，而不是加载整个模块，这种加载称为“编译时加载”。

CommonJS 加载的是一个对象（即module.exports属性），该对象只有在脚本运行完才会生成。而 ES6 模块不是对象，它的对外接口只是一种静态定义，在代码静态解析阶段就会生成。

一点说明：本文只是自己的一点笔记，方便自己记忆和理解。\(^o^)/~

作者：sunxiaoying123
链接：https://juejin.im/post/5b4420e7f265da0f4b7a7b27
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。