2.3.1 模块化

根据 12-Factor 规则 ，一项软件工程应当能够以显性的方式表达其依赖性，如Perl的CPAN 或是Ruby的Rubygems 。而ES2015 以前的ECMAScript并不能完成这一点，这也是一直以来许多使用其他语言的工程师诟病ECMAScript系语言（尤其是JavaScript）的原因之一。

而在JavaScript领域中，模块化的需求是越来越强了。从以前简单的页面开发，到如今达到了复杂的GUI开发水平，JavaScript或是ECMAScript越来越需要更为详细的模块化机制，以应对越来越复杂的工程需求。前端模块化如图 2.1 所示。

而在Node.js 开始流行起来时，由Isaac Z. Schlueter开发的NPM 则成为了JavaScript世界中最为流行的JavaScript模块管理平台。这满足了 12-Factor中模块化的“硬件要求”，但是在JavaScript部分依然需要以CommonJS的形式进行获取依赖。

因为ECMAScript或JavaScript自身并没有类似的标准，因此TC-39 便决定在ECMAScript中加入原生的模块化标准，以解决多年来困扰众多JavaScript开发者的问题。

从许多年前开始，各大公司、团队和技术牛人都相继给出了他们对于这个问题的不同解决方案，由此定下了如CommonJS、AMD、CMD或UMD等JavaScript模块化标准。RequireJS 、SeaJS 、FIS 、Browserify 、webpack 等模块加载库都以各自不同的优势占领着一方土地，如图 2.2 所示。

而对于大部分的JavaScript程序员来说，有太多不同的选择会让他们感到不安和迷茫，他们并不能从中选择最适合自己的一种，这也导致了分门立派的情况出现。

TC-39 在ES2015 中为ECMAScript新增的原生模块化标准，正是为了解决该问题。它包含了以往的模块加载库的主要功能，还添加了一些非常实用的设计，用来提高ECMAScript的模块化管理能力。

可惜的是，到本书截稿之时，还没有任何浏览器厂商或是JavaScript引擎支持这种模块化语法，所以需要用Babel将其转换为CommonJS、AMD或是UMD等模块化标准的语法。

而对于CommonJS等模块化方法来说，ES2015 原生的模块化机制更为详细和实用，比如其中的 模块内容选择性引入 ，更是为JavaScript的工程化提供了更多的想象空间，比如更高程度的项目代码压缩。

上面这一段代码可以通过一些方法来进行依赖分析，并进行压缩，如 main.js中引入了module_a中的add函数，而在module_a中还定义了substract并没有被引用或调用。这样的话，最后就可以把这段代码压缩成以下的形式。

这在Web前端领域中有着非常大的意义，因为在一个现代的JavaScript应用中，很难避免会使用一个第三方框架或者类库以加快开发速度。但是在大部分情况下，这些框架或者类库中有很多方法是实际应用中用不到的，而以往的压缩手段并不会将这些没有被使用的代码去掉，因此造成了大量的冗余。

因为在前端领域中，无论对于开发者还是用户来说，代码压缩都是必要的，昂贵的网络带宽和较慢的页面加载速度都极大程度地影响着应用的体验和运营。如AngularJS 、React 、Vue.js 、Lodash 等第三方库或框架中有许多JavaScript应用在技术选型时的一些重要选项，而在这些库中存在许多开发中不需要的方法，如果将它们完整地引入到应用中，它们就会成为应用中的“体积大户”，开发者和用户却只能无奈地接受。

而Rollup和webpack 2 则可以利用ES2015 中的模块化机制来最大程度地精简JavaScript应用的体积，它们通过分析JavaScript的抽象语法树、依赖检查等步骤，建立一个“对象依赖树”，并借此将所有被引用或被使用的对象抽出，合成为最小可用程序集，供生产环境使用。 eXw5gRJdMtOvOluH722Y7T4qYIk1bOkGM3hpuWkNo3QcK2ryrTwOr3E5FgtxAeVz