面对 ESM，webpack 还有还手之力吗？

snowpack / vite 等基于 ESM 的构建工具出现，让项目的工程构建不再需要构建一个完整的 bundle。很多人都觉得我们不再需要打包工具的时代即将到来。借助浏览器 ESM 的能力，一些代码基本可以做到无需构建直接运行。

对于 webpack 而言，社区掀起的这一波 ESM 热潮，将 webpack 编译的速度推到了风口浪尖。webpack 在 v5 版本中也是针对编译的性能做出了不少努力，除了提供了物理缓存的优化之外，还提供 Module Federation 的方案，这给我们上层的应用实践带来了很多想象的空间。

以前 webpack 大有一统构建工具的趋势，而现在我们可以结合业务的特点有更多的选择。

为什么需要打包JavaScript

编程过程中很多时候，我们都在修改变量，在一个复杂的项目开发过程中，如何管理函数和变量作用域，显得尤为重要。而 JavaScript 的模块化提供了我们更好的方式来组织和维护函数以及变量。大家熟知的 JavaScript 模块除了上述的 ESM 之外，还有 CJS、AMD、CMD、UMD 等等规范。

而在 npm 生态开发的背景下，CJS 模块是开发过程中接触最多也是无法避免的。但由于浏览器并不能直接执行基于 CJS 打包的模块，因此类似 webpack 等打包工具便应运而生。

对于早期的 web 应用而言，打包模块既能够处理 JS 模块化，又能将多个模块打包合并网络请求。使用这类构建工具打包项目的确是个不错的选择。时至今日基本上主流的浏览器版本都支持 ESM，并且并发网络请求带来的性能问题，在 HTTP/2 普及下不像以前那么凸显的情况下，大家又将目光转向了 ESM。就目前的体验而言，基于原生 ESM 在开发过程中的构建速度似乎远远优于 webpack 之类的打包工具的。

初探 ESM 构建工具

使用 ESM

<script src="index.js" type="module"></script>

通过 type="module" 告诉浏览器，当前脚本使用 ESM 模式，浏览器会构建一个依赖关系图，借助浏览器原生的 ESM 能力完成模块的查找、解析、实例化到执行的过程。

为什么快

为什么基于 ESM 的构建工具 snowpack / vite 会比 webpack 在构建的时候要快很多，借用 snowpack 官网的一张图片来说明：

最核心的两个特点：

1、首先它们的构建复杂度非常低，修改任何组件都只需做单文件编译，时间复杂度永远是 O(1)

2、借助 ESM 的能力，模块化交给浏览器端，不存在资源重复加载问题，如果不是涉及到 jsx 或者 typescript 语法，甚至可以不用编译直接运行