javascript模块化、模块加载器初探

rou 2013-07-30

最常见网站的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的方式编写。 

相关推荐