Webpack实战:入门、进阶与调优
上QQ阅读APP看书,第一时间看更新

1.2.2 JavaScript中的模块

在大多数程序语言中(如C、C++、Java),开发者都可以直接使用模块化进行开发。工程中的各个模块在经过编译、链接等过程后会被整合成单一的可执行文件并交由系统运行。

对于JavaScript来说,情况则有所不同。在过去的很长一段时间里,JavaScript这门语言并没有模块这一概念。如果工程中有多个JS文件,我们只能通过script标签将它们一个个插入页面中。

为何偏偏JavaScript没有模块呢?如果要追溯历史原因,JavaScript之父——Brendan Eich最初设计这门语言时只是将它定位成一个小型的脚本语言,用来实现网页上一些简单的动态特性,远没有考虑到会用它实现今天这样复杂的场景,模块化当然也就显得多余了。

随着技术的发展,JavaScript已经不仅仅用来实现简单的表单提交等功能,引入多个script文件到页面中逐渐成为一种常态,但我们发现这种做法有很多缺点:

·需要手动维护JavaScript的加载顺序。页面的多个script之间通常会有依赖关系,但由于这种依赖关系是隐式的,除了添加注释以外很难清晰地指明谁依赖了谁,这样当页面中加载的文件过多时就很容易出现问题。

·每一个script标签都意味着需要向服务器请求一次静态资源,在HTTP 2还没出现的时期,建立连接的成本是很高的,过多的请求会严重拖慢网页的渲染速度。

·在每个script标签中,顶层作用域即全局作用域,如果没有任何处理而直接在代码中进行变量或函数声明,就会造成全局作用域的污染。

模块化则解决了上述的所有问题。

·通过导入和导出语句我们可以清晰地看到模块间的依赖关系,这点在后面会做详细的介绍。

·模块可以借助工具来进行打包,在页面中只需要加载合并后的资源文件,减少了网络开销。

·多个模块之间的作用域是隔离的,彼此不会有命名冲突。

从2009年开始,JavaScript社区开始对模块化进行不断的尝试,并依次出现了AMD、CommonJS、CMD等解决方案。但这些都只是由社区提出的,并不能算语言本身的特性。而在2015年,ECMAScript 6.0(ES6)正式定义了JavaScript模块标准,使这门语言在诞生了20年之后终于拥有了模块这一概念。

ES6模块标准目前已经得到了大多数现代浏览器的支持,但在实际应用方面还需要等待一段时间。主要有以下几点原因:

·无法使用code splitting和tree shaking(Webpack的两个特别重要的特性,之后的章节会介绍)。

·大多数npm模块还是CommonJS的形式,而浏览器并不支持其语法,因此这些包没有办法直接拿来用。

·仍然需要考虑个别浏览器及平台的兼容性问题。

那么,如何才能让我们的工程在使用模块化的同时也能正常运行在浏览器中呢?这就到了模块打包工具出场的时候了。