最常见网站的javascript架构可能是这样的：
- 一个底层框架文件，如jQuery
- 一个网站业务框架文件，包含整站公用业务模块类(如弹框、ajax封装等)
- 多个业务文件，包含每个具体页面有关系的业务代码
为了减少一个HTTP请求，我们可能将底层框架文件和网站业务框架文件combo成一个文件，作为一个公用文件引入到每个需要使用javascript的页面中，再在具体的页面中引入和当前页相关业务js文件。为了减少页面加载脚本阻塞现象，我们还可以将脚本文件放在html的body底部进行加载。
这看似是一个很好的javascript架构方案。每个页面最多引用两个js文件，打开首页后，后续页面都可以使用缓存中的combo过的js。如果底层框架改动不太频繁，那么缓存在用户浏览器中的combo过的框架文件能够使用较长的时间。
当网站使用过一段时间后，你可能就会发现一些问题出来了。
- combo过的框架文件过大。虽然可以使用YUI Compressor或Google Clousure等第三方压缩工具压缩、启用gzip、使用CDN等优化手段优化。但底层框架会随着开源框架升级，公用模块增多，导致combo后的框架文件越来越大。
- 业务框架改动频繁，导致浏览器缓存作用减小。由于业务的增加，可能公用的业务模块越来越多，导致业务框架频繁修改。代码修改后，浏览器需要重新加载新的框架文件。
- 团队开发问题。随着团队人数的增加，可能每个人开发一个公用业务模块，造成多人需要对同一个文件进行修改。若使用TFS这种独占式签出的版本管理工具，会对团队的开发效率造成一定影响。
我们再看看使用模块加载器、并对javascript进行过模块化处理的网站的javascript架构：
- 一个模块加载器文件。如loader.js
- 多个底层模块(如selector、ua等)，多个业务模块(如dialog、suggest等)
- 多个页面相关的脚本调用文件
优点体现出来了：
- 按需加载：只加载当前页面需要的模块和文件，不需加载任何多余文件和代码。大大缩减了代码量
- 并行加载：很多loader提供了并行加载多个文件的功能，减少了代码加载的时间，优点能做到下载和执行相分离。
- 利于团队开发：团队中每个人负责开发各自的模块，之间互不影响。
- 最大限度的利用缓存：模块颗粒化后，每次更新可能只是其中一个小模块，其他未更新的可以利用浏览器中的缓存。
既然javascript模块化、使用模块加载器有这么多的好处，那么我们需要付出哪些努力：
- 选用或实现loader
- 底层框架的模块化：我们需要将底层框架按照各自的只能分成不同的模块，分清楚之间的依赖关系
- 实现业务模块：将原来的业务模块按照loader约定的代码方式进行修改，实现新的业务模块按照loader的方式编写。
