if(xx){

     //.......

}

else{

     //xxxxxxxxxxx

}

for(var i=; i<; i++){

     //........

}

element.onclick = function(){

     //.......

}

2009年，nodejs横空出世，开创了一个新纪元，人们可以用js来编写服务端的代码了。如果说浏览器端的js即便没有模块化也可以忍的话，那服务端是万万不能的。

大牛云集的CommonJs社区发力，制定了Modules/1.0（http://wiki.commonjs.org/wiki/Modules/1.0）规范，首次定义了一个模块应该长啥样。具体来说，Modules/1.0规范包含以下内容：

此规范一出，立刻产生了良好的效果，由于其简单而直接，在nodejs中，这种模块化方案立刻被推广开了。

遵循commonjs规范的代码看起来是这样的：（来自官方的例子）

//math.js

exports.add = function() {

    var sum = , i = , 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, );

};

//program.js

var inc = require('increment').increment;

var a = ;

inc(a); //

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

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

2. 资源的加载方式与服务端完全不同。服务端require一个模块，直接就从硬盘或者内存中读取了，消耗的时间可以忽略。而浏览器则不同，需要从服务端来下载这个文件，然后运行里面的代码才能得到API，需要花费一个http请求，也就是说，require后面的一行代码，需要资源请求完成才能执行。由于浏览器端是以插入<script>标签的形式来加载资源的（ajax方式不行，有跨域问题），没办法让代码同步执行，所以像commonjs那样的写法会直接报错。

 

所以，社区意识到，要想在浏览器环境中也能模块化，需要对规范进行升级。顺便说一句，CommonJs原来是叫ServerJs，从名字可以看出是专攻服务端的，为了统一前后端而改名CommonJs。（论起名的重要性~）

而就在社区讨论制定下一版规范的时候，内部发生了比较大的分歧，分裂出了三个主张，渐渐的形成三个不同的派别：

这一波人认为，在现有基础上进行改进即可满足浏览器端的需要，既然浏览器端需要function包装，需要异步加载，那么新增一个方案，能把现有模块转化为适合浏览器端的就行了，有点像“保皇派”。基于这个主张，制定了Modules/Transport（http://wiki.commonjs.org/wiki/Modules/Transport）规范，提出了先通过工具把现有模块转化为复合浏览器上使用的模块，然后再使用的方案。

browserify就是这样一个工具，可以把nodejs的模块编译成浏览器可用的模块。（Modules/Transport规范晦涩难懂，我也不确定browserify跟它是何关联，有知道的朋友可以讲一下）

目前的最新版是Modules/1.1.1（http://wiki.commonjs.org/wiki/Modules/1.1.1），增加了一些require的属性，以及模块内增加module变量来描述模块信息，变动不大。

 2. Modules/Async派

这一波人有点像“革新派”，他们认为浏览器与服务器环境差别太大，不能沿用旧的模块标准。既然浏览器必须异步加载代码，那么模块在定义的时候就必须指明所依赖的模块，然后把本模块的代码写在回调函数里。模块的加载也是通过下载-回调这样的过程来进行，这个思想就是AMD的基础，由于“革新派”与“保皇派”的思想无法达成一致，最终从CommonJs中分裂了出去，独立制定了浏览器端的js模块化规范AMD（Asynchronous Module Definition）（https://github.com/amdjs/amdjs-api/wiki/AMD）

本文后续会继续讨论AMD规范的内容。

这一波人有点像“中间派”，既不想丢掉旧的规范，也不想像AMD那样推到重来。他们认为，Modules/1.0固然不适合浏览器，但它里面的一些理念还是很好的，（如通过require来声明依赖），新的规范应该兼容这些，AMD规范也有它好的地方（例如模块的预先加载以及通过return可以暴漏任意类型的数据，而不是像commonjs那样exports只能为object），也应采纳。最终他们制定了一个Modules/Wrappings（http://wiki.commonjs.org/wiki/Modules/Wrappings）规范，此规范指出了一个模块应该如何“包装”，包含以下内容：

使用该规范的例子看起来像这样：

//可以使用exprots来对外暴漏API

module.declare(function(require, exports, module)

{

    exports.foo = "bar";

});

//也可以直接return来对外暴漏数据

module.declare(function(require)

{

return { foo: "bar" };

});

AMD的思想正如其名，异步加载所需的模块，然后在回调函数中执行主逻辑。这正是我们在浏览器端开发所习惯了的方式，其作者亲自实现了符合AMD规范的requirejs，AMD/RequireJs迅速被广大开发者所接受。

AMD规范包含以下内容：

基于以上几点基本规范，我们便可以用这样的方式来进行模块化组织代码了：

//a.js

define(function(){

     console.log('a.js执行');

     return {

          hello: function(){

               console.log('hello, a.js');

          }

     }

});

//b.js

define(function(){

     console.log('b.js执行');

     return {

          hello: function(){

               console.log('hello, b.js');

          }

     }

});

//main.js

require(['a', 'b'], function(a, b){

     console.log('main.js执行');

     a.hello();

     $('#b').click(function(){

          b.hello();

     });

})

上面的main.js被执行的时候，会有如下的输出：

a.js执行
b.js执行
main.js执行
hello, a.js

在点击按钮后，会输出：

hello, b.js

这结局，如你所愿吗？大体来看，是没什么问题的，因为你要的两个hello方法都正确的执行了。

但是如果细细来看，b.js被预先加载并且预先执行了，（第二行输出），b.hello这个方法是在点击了按钮之后才会执行，如果用户压根就没点，那么b.js中的代码应不应该执行呢？

这其实也是AMD/RequireJs被吐槽的一点，预先下载没什么争议，由于浏览器的环境特点，被依赖的模块肯定要预先下载的。问题在于，是否需要预先执行？如果一个模块依赖了十个其他模块，那么在本模块的代码执行之前，要先把其他十个模块的代码都执行一遍，不管这些模块是不是马上会被用到。这个性能消耗是不容忽视的。

另一点被吐槽的是，在定义模块的时候，要把所有依赖模块都罗列一遍，而且还要在factory中作为形参传进去，要写两遍很大一串模块名称，像这样：

define(function(){

     console.log('main2.js执行');

     require(['a'], function(a){

          a.hello();

     });

     $('#b').click(function(){

          require(['b'], function(b){

               b.hello();

          });

     });

});

我们在define的参数中未写明依赖，那么main2.js在执行的时候，就不会预先加载a.js和b.js，只是执行到require语句的时候才会去加载，上述代码的输出如下：

main2.js执行
a.js执行
hello, a.js

可以看到b.js并未执行，从网络请求中看，b.js也并未被下载。只有在按钮被点击的时候b.js才会被下载执行，并且在回调函数中执行模块中的方法。这就是名副其实的“懒加载”了。

 

这样的懒加载无疑会大大减轻初始化时的损耗（下载和执行都被省去了），但是弊端也是显而易见的，在后续执行a.hello和b.hello时，必须得实时下载代码然后在回调中才能执行，这样的用户体验是不好的，用户的操作会有明显的延迟卡顿。

但这样的现实并非是无法接受的，毕竟是浏览器环境，我们已经习惯了操作网页时伴随的各种loading。。。

 

但是话说过来，有没有更好的方法来处理问题呢？资源的下载阶段还是预先进行，资源执行阶段后置，等到需要的时候再执行。这样一种折衷的方式，能够融合前面两种方式的优点，而又回避了缺点。

这就是Modules/Wrappings规范，还记得前面提到的“中间派”吗？

在AMD的阵营中，也有一部分人提出这样的观点，代码里写一堆回调实在是太恶心了，他们更喜欢这样来使用模块：

 

 

兼容并包的CMD/seajs

既然requirejs有上述种种不甚优雅的地方，所以必然会有新东西来完善它，这就是后起之秀seajs，seajs的作者是国内大牛淘宝前端步道者玉伯。seajs全面拥抱Modules/Wrappings规范，不用requirejs那样回调的方式来编写模块。而它也不是完全按照Modules/Wrappings规范，seajs并没有使用declare来定义模块，而是使用和requirejs一样的define，或许作者本人更喜欢这个名字吧。（然而这或多或少又会给人们造成理解上的混淆），用seajs定义模块的写法如下：

//a.js

define(function(require, exports, module){

     console.log('a.js执行');

     return {

          hello: function(){

               console.log('hello, a.js');

          }

     }

});

//b.js

define(function(require, exports, module){

     console.log('b.js执行');

     return {

          hello: function(){

               console.log('hello, b.js');

          }

     }

});

//main.js

define(function(require, exports, module){

     console.log('main.js执行');

     var a = require('a');

     a.hello();    

     $('#b').click(function(){

          var b = require('b');

          b.hello();

     });

});

定义模块时无需罗列依赖数组，在factory函数中需传入形参require,exports,module，然后它会调用factory函数的toString方法，对函数的内容进行正则匹配，通过匹配到的require语句来分析依赖，这样就真正实现了commonjs风格的代码。

上面的main.js执行会输出如下：

main.js执行
a.js执行
hello, a.js

a.js和b.js都会预先下载，但是b.js中的代码却没有执行，因为还没有点击按钮。当点击按钮的时候，会输出如下：

b.js执行
hello, b.js

可以看到b.js中的代码此时才执行。这样就真正实现了“就近书写，延迟执行“，不可谓不优雅。

 

如果你一定要挑出一点不爽的话，那就是b.js的预先下载了。你可能不太想一开始就下载好所有的资源，希望像requirejs那样，等点击按钮的时候再开始下载b.js。本着兼容并包的思想，seajs也实现了这一功能，提供require.async API，在点击按钮的时候，只需这样写：

var b = require.async('b');

b.hello();

b.js就不会在一开始的时候就加载了。这个API可以说是简单漂亮。

 

关于模块对外暴漏API的方式，seajs也是融合了各家之长，支持commonjs的exports.xxx = xxx和module.exports = xxx的写法，也支持AMD的return写法，暴露的API可以是任意类型。

 

你可能会觉得seajs无非就是一个抄，把别人家的优点都抄过来组合了一下。其实不然，seajs是commonjs规范在浏览器端的践行者，对于requirejs的优点也加以吸收。看人家的名字，就是海纳百川之意。（再论起名的重要性~），既然它的思想是海纳百川，讨论是不是抄就没意义了。

鉴于seajs融合了太多的东西，已经无法说它遵循哪个规范了，所以玉伯干脆就自立门户，起名曰CMD（Common Module Definition）规范，有了纲领，就不会再存在非议了。