如今模块化的 JavaScript 的开发越来越火热，无论是模块加载器还是优秀的 JavaScript 模块，都是层出不穷。既然这么火，肯定是有存在的理由，肯定是解决了某些实际问题。很多没接触过模块化 JavaScript 开发者不禁要问，我真的需要模块化吗，模块化相比于传统的模式有什么优势？
JavaScript 本身是没有模块化支持的，很多语言多有，就连 CSS 都有这样的加载方式。
虽然因为性能问题不推荐 CSS 这样来进行加载，但这是一种模块化的思想，这种思想对于 JavaScript 来说很有用。幸好 JavaScript 是一门灵活的语言，可以通过下面这段代码来进行动态加载 JavaScript 文件。
传统的加载方式必须在页面中放置一个 script 标签来进行加载。
<script type="text/javascript" src="http://example.com/test.js"></script>
更好的分离
那如果要加载多个就得放置多个 script 标签，如果是加载模块的话，拿 easy.js 来说，页面中始终只要引用 easy.js 即可，这样对于 HTML 和 JavaScript 分离很有好处，在某些场景下这个分离度很重要。
就拿我司的情况来说吧。后端的 view 层并不是由我们前端来开发的，项目上线的时候，前端只能更新 CSS 和 JS 文件，HTML 文件动不了。如果前端要在该页面新增一个 JavaScript 文件的引用是很麻烦的，因为后端程序的更新都要严格按照流程来并有固定的更新时间，如果是用模块加载的方式不用再理会后端的更新。当然，你也许会说，如果原页面中已经有 JavaScript 文件，我直接在原文件中加代码不就行了，那么接下来说说直接在原文件中新增代码会碰到什么样的问题。
更好的代码组织方式
如果单个文件越来越大，维护起来出问题的几率也会越来越大，一个人开发还好，如果是多人开发，不同的代码风格，超多的业务逻辑混杂在一起，不要说维护了，光想想都蛋痛。模块式的开发，一个文件就是一个模块，控制了文件的粒度，每个模块可以专注于一个功能。正所谓一个萝卜一个坑，多人开发时，各自管好自己坑里的萝卜就行了，这也正是 OOP 的思想。
按需加载
还是围绕单个文件来说事，当文件大到一定的程度，性能问题也随之而来了。合并文件是能减少请求，这是会带来性能的提升，但是当文件大到一定的体积时，此时的下载时间可能并不会比多个小文件的下载时间更短。此时就需要权衡请求数和文件体积的关系了。
单文件还有一个问题，那就是缓存是否能充分的利用好。如果一个大体积的文件内包含了超多的业务逻辑和复杂的功能，而这个文件同时又被很多页面引用到。比如在某页面，实际只用到了该文件一个很少的功能，那么其他的代码对于该页面来说就是多余的，浪费了加载流量。你或许会说，这个文件虽然大，但是它第一次加载的时候就被缓存过了，尽管在某页面只用到了极少部分的功能，但只要缓存过，加载还是挺快的。是的，如果情况有这么理想肯定是好事。但是，往往理想和现实都会有差距，如果产品的迭代更新太快，业务需求一天一个样，那么该文件就会三天两头的更新，更新可能是一个很小的功能，但是这样的更新对于刷新缓存的代价可是很大的。如果确实有这种情况，就说明这种设计确实是有问题。如果能合理的对文件进行模块化的管理，那么可以尽量减少不必要的加载，尽量减少刷新大文件的缓存带来的损失，这也需要权衡好，比如将很少更新的合并成一个文件，常更新的独立成模块。
避免命名冲突
JavaScript 本身是没有命名空间的，为了避免命名冲突，经常会使用对象和闭包的办法来避免。用对象仅仅是降低了冲突的概率而已，拿经常使用 jQuery 的开发来说，无论是往 $ 上扩展还是在 $.fn 上扩展，人多了难免会起冲突。或者用自定义的对象，搞个好几层，不光是写起来难记，这样的调用也会在性能上打折扣的。模块化就很好的解决了这个问题，在该模块内的任何形式的命名都不会再和其他模块有冲突，你想起啥名都行了。当然，你硬要在模块内部给 window 上挂一堆东西，我也没办法。
既然每个模块都是封闭式的，那么模块之间如何通信呢？接口的设计那是必须的。很简单，对于像 seajs 这种 CMD 规范的，需要使用自定义的关键字来向外部暴露一个接口。
define(function( require, exports ){
var hello = ‘hello world‘;
// 向外部暴露该模块的接口
exports.hello = hello;
});
easy.js 遵循 AMD 规范，暴露接口更简单，直接用 return 关键词即可。
define( ‘hello‘, function(){
var hello = ‘hello world‘;
// 向外部暴露该模块的接口
return hello;
});
更好的依赖处理
传统的开发模式，如果 B 文件要依赖 A 文件，那么必须在 B 文件前面用 script 的形式先加载好 A 文件。如果有一天，B 文件不再需要依赖 A 文件，或者要增加依赖文件 C，那么又回到了我说的第一个问题上。如果这个 B 文件被 N 个页面在调用，而且页面还跨业务站点，那改起来简直就是噩梦啊。如果是用模块化，只需要在模块内部声明好依赖就行了，增加删除都直接修改模块即可。调用的时候也不用管该模块依赖了哪些其他模块，放心的用就是了。
好了，讲了这么多，如果你还是觉得无动于衷，要么是你接触到的项目较小，还没复杂到这个程度，要么就是我的表达能力有问题。如果你觉得还有什么需要补充的，欢迎在下面留言。
原载于：雨夜带刀‘s Blog
本文链接：http://stylechen.com/modular-javascript.html
如需转载请以链接形式注明原载或原文地址。