js模块化开发演进

一、非JS模块化的痛苦

1. 全局变量过多
2. 命名冲突
   见上一篇文章
3. 文件依赖不好管理
   假如有个util.js,后面又写了个helper.js依赖util.js,后面又有个a.js依赖helper.js,那页面引入的顺序就不能改变。

<script src="util.js"></script>
<script src="helper.js"></script>
<script src="a.js"></script>

如果顺序不小心被改变了，就会出现很多问题。

二、模块化解决方案

CommonJS,seaJS,AMD,CMD,UMD,Browserify,RequireJS

1. CommonJS && nodejs
   CommonJS社区 首先提出了模块化的规范CommonJS，所以CommonJS是一个规范。
   nodeJS实现了这种规范

   a.js
   exports.add = function(a,b){
   	return a+b;
   }
   
   b.js 
   var add = require('a.js').add;
   console.log(add(1,2))//3
   

2. CommonJS && Browserify
   既然服务端实现了这种模块化的规范，浏览器上对此也是非常迫切的，但是直接拿来用是有一些问题:
   a. node中require是同步加载的，直接从内存或硬盘里读就可以了。
   而在浏览器上不能同步加载，因为浏览器上每一个文件都是需要下载下来的，需要时间，而且浏览器上下载js都是通过script来加载的，不能同步执行，所以也就没办法同步加载模块了。
   b. 没有立即执行函数的包裹，加载的模块变量又暴露在全局上了。

   因此如果想在浏览器上使用CommonJS是需要改造的，对此人们分成了几派:
   一派认为还是按照CommonJS规范来，只是加上函数包裹和异步加载，在浏览器上能执行就行了；
   一派认为CommonJS不适合浏览器端，需要一个新的规范；
   第三方是个“和稀泥”的，认为CommonJS和重新改革都有可取之处，所以各取所长。

   Browserify就是第一派坚持使用CommonJS做出来的浏览器端的实现。

3. AMD && RequireJS
   AMD就是上面说的第二派：抛弃CommonJS，提出新的可异步加载的模块规范。
   AMD最大的特点是可以异步加载模块，它的实现是RequireJS

   // math.js 定义方法
   define(function () {
     var add = function (x, y) { return x + y; };
     return {
       add: add
     };
   });
   // main.js 加载方法
   require(['math'], function (math) {
     console.log(math.add(1, 1));
   });
   
   
   require(['myModule', 'myOtherModule'],function(myModule, myOtherModule) {
   	console.log(myModule.hello());
   });
   

   过程是先加载依赖myModule，myOtherModule（后台不阻塞的方式加载），加载完成后执行回调函数，其中回调函数的参数便是已经加载完成的模块。其实AMD还是有很多问题的，比如define的时候所有依赖要挨个写一遍，比如不管现在用不用的到都会把依赖先下载下来，不过这些问题AMD都有优化，这里不提。

4. UMD
   UMD全称是Universal Module Definition，目的兼容CommonJS和AMD，所以它会做一层判断，判断当前环境是浏览器还是node，如果是浏览器则使用AMD，node环境使用CommonJS方式，UMD实现了两种环境的兼容，但同时也导致了十分臃肿。

5. CMD && seaJS
   seaJS是阿里前端工程师玉伯做出来的，并提出了CMD，CMD吸取了AMD和CommonJS两者的优点，融合了百家之长（但好像只在国内有影响，国外影响有限），所以CMD是规范而seajs是它的实现。

define(function(require,exports,module){...});

seajs只会在震中需要使用依赖模块时才执行该模块
参考文章