js模块化开发演进

一、非JS模块化的痛苦

全局变量过多命名冲突 见上一篇文章文件依赖不好管理 假如有个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

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

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

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

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

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都有优化，这里不提。

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

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

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

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