JavaScript 模块化历程

原文链接：http://www.cnblogs.com/lvdabao/p/js-modules-develop.html

image.png

这是一篇关于 js 模块化历程的长长的流水账，记录js模块化思想的诞生与变迁，展望ES6模块化标准的未来。经历过这段历史的人或许会感到沧桑，没经历过的人也应该知道这段历史。

无模块时代

在 Ajax 还未提出之前，js还只是一种“玩具语言”，由 Brendan Eich 花了不到十天时间发明，用来在网页上进行表单校验、实现简单的动画效果等等，你可以回想一下那个网页上到处有公告块飘来飘去的时代。
　　这个时候并没有前端工程师，服务端工程师只需在页面上随便写写 js 就能搞定需求。那个时候的前端代码大概像这样：

if(xx){
     //.......
}
else{
     //xxxxxxxxxxx
}
for(var i=0; i<10; i++){
     //........
}
element.onclick = function(){
     //.......
}

代码简单的堆在一起，只要能从上往下依次执行就可以了。

模块萌芽时代

2006 年，Ajax 的概念被提出，前端拥有了主动向服务端发送请求并操作返回数据的能力，随着 Google 将此概念的发扬光大，传统的网页慢慢的向“富客户端”发展。前端的业务逻辑越来越多，代码也越来越多，于是一些问题就暴漏了出来：

全局变量的灾难
张三定义了：i = 1
李四在后续的代码里：i=0
张三在接下来的代码里：if(i==1){...} //悲剧
函数命名冲突
项目中通常会把一些通用的函数封装成一个文件，常见的名字有 utils.js、common.js……
张三定义了一个函数：function formatData(){ }
李四想实现类似功能，于是这么写：function formatData2(){ }
王五又有一个类似功能，于是：function formatData3(){ }
……
避免命名冲突就只能这样靠丑陋的方式人肉进行。
依赖关系不好管理
b.js 依赖 a.js，标签的书写顺序必须是

顺序不能错，也不能漏写某个。在多人开发的时候很难协调。
尤其在开发单页应用的时候，所有引用都要写在 index.html 里面，这种现象尤为明显！

萌芽时代的解决方案：

用自执行函数来包装代码

modA = function(){
     var a,b; //变量a、b外部不可见
     return {
          add : function(c){
               a + b + c;
          },
          format: function(){
               //......
          }
     }
}()

这样 function 内部的变量就对全局隐藏了，达到是封装的目的。但是这样还是有缺陷的，modA这个变量还是暴漏到全局了，随着模块的增多，全局变量还是会越来越多。

Java风格的命名空间
　　为了避免全局变量造成的冲突，人们想到或许可以用多级命名空间来进行管理，于是，代码就变成了这个风格：

app.util.modA = xxx;
app.tools.modA = xxx;
app.tools.modA.format = xxx;

Yahoo的YUI早期就是这么做的，调用的时候不得不这么写：

app.tools.modA.format();

这样调用函数，写写都会觉得恶心，所以这种方式并没有被很多人采用，YUI后来也不用这种方式了。

jQuery风格的匿名自执行函数

(function(window){
    //代码
    window.jQuery = window.$ = jQuery;//通过给window添加属性而暴漏到全局
})(window);

jQuery的封装风格曾经被很多框架模仿，通过匿名函数包装代码，所依赖的外部变量传给这个函数，在函数内部可以使用这些依赖，然后在函数的最后把模块自身暴漏给 window。
　　如果需要添加扩展，则可以作为jQuery的插件，把它挂载到$上。
　　这种风格虽然灵活了些，但并未解决根本问题：所需依赖还是得外部提前提供、还是增加了全局变量。

模块化面临什么问题

从以上的尝试中，可以归纳出 js 模块化需要解决那些问题：

如何安全的包装一个模块的代码？（不污染模块外的任何代码）
如何唯一标识一个模块？
如何优雅的把模块的API暴漏出去？（不能增加全局变量）
如何方便的使用所依赖的模块？
围绕着这些问题，js 模块化开始了一段艰苦而曲折的征途。

源自 Nodejs 的规范 CommonJS

2009 年，Nodejs 横空出世，开创了一个新纪元，人们可以用 js 来编写服务端的代码了。如果说浏览器端的 js 即便没有模块化也可以忍的话，那服务端是万万不能的。
　　大牛云集的 CommonJS 社区发力，制定了 Modules/1.0 规范，首次定义了一个模块应该长啥样。具体来说，Modules/1.0 规范包含以下内容：

模块的标识应遵循的规则（书写规范）

定义全局函数 require，通过传入模块标识来引入其他模块，执行的结果即为别的模块暴漏出来的 API

如果被 require 函数引入的模块中也包含依赖，那么依次加载这些依赖

如果引入模块失败，那么 require 函数应该报一个异常

模块通过变量 exports 来向往暴漏 API，exports 只能是一个对象，暴漏的 API 须作为此对象的属性。

此规范一出，立刻产生了良好的效果，由于其简单而直接，在 Nodejs 中，这种模块化方案立刻被推广开了。
　　遵循 CommonJS 规范的代码看起来是这样的：（来自官方的例子）

//math.js
exports.add = function() {
    var sum = 0, i = 0, args = arguments, l = args.length;
    while (i < l) {
        sum += args[i++];
    }
    return sum;
};

//increment.js
var add = require('math').add;
exports.increment = function(val) {
    return add(val, 1);
};

//program.js
var inc = require('increment').increment;
var a = 1;
inc(a); // 2

服务端向前端进军

Modules/1.0规范源于服务端，无法直接用于浏览器端，原因表现为：

外层没有 function 包裹，变量全暴漏在全局。如上面例子中 increment.js 中的 add。

资源的加载方式与服务端完全不同。服务端 require 一个模块，直接就从硬盘或者内存中读取了，消耗的时间可以忽略。而浏览器则不同，需要从服务端来下载这个文件，然后运行里面的代码才能得到 API，需要花费一个 http 请求，也就是说，require 后面的一行代码，需要资源请求完成才能执行。由于浏览器端是以插入