如今模块化的 JavaScript 的开发越来越火热，无论是模块加载器还是优秀的 JavaScript 模块，都是层出不穷。既然这么火，肯定是有存在的理由，肯定是解决了某些实际问题。很多没接触过模块化 JavaScript 开发者不禁要问，我真的需要模块化吗，模块化相比于传统的模式有什么优势？
JavaScript 本身是没有模块化支持的，很多语言多有，就连 CSS 都有这样的加载方式。
虽然因为性能问题不推荐 CSS 这样来进行加载，但这是一种模块化的思想，这种思想对于 JavaScript 来说很有用。幸好 JavaScript 是一门灵活的语言，可以通过下面这段代码来进行动态加载 JavaScript 文件。
传统的加载方式必须在页面中放置一个 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 个页面在调用，而且页面还跨业务站点，那改起来简直就是噩梦啊。如果是用模块化，只需要在模块内部声明好依赖就行了，增加删除都直接修改模块即可。调用的时候也不用管该模块依赖了哪些其他模块，放心的用就是了。
好了，讲了这么多，如果你还是觉得无动于衷，要么是你接触到的项目较小，还没复杂到这个程度，要么就是我的表达能力有问题。如果你觉得还有什么需要补充的，欢迎在下面留言。