2022-04-02 更新：增加测评 JS Compiler 的测试数据
2022-03-21 更新：增加测评 Bundler 和 JS Minifier 的测试数据
前端构建工具已经形成了一个或多个复杂的生态系统。从最基础的 webpack, rollup 和 babel, esbuild, swc 等工具库，衍生出各种各样的插件，封装组合成 crate-react-app, vite, parcel, snowpack 这样通用解决方案，进而发展出 Next.js, ICE.js, UMI.js 这种特异化的行业解决方案。
这个生态中的每个部分，都有其替代品。比如 swc 可以替代 babel, rollup 可以替代 webpack。swc 确实比 babel 快得多，但是插件生态不如 babel 全面，两者互有胜负。项目的实际需求，决定了构建工具的选型。
随着前端工程越来越大，构建性能和热加载性能逐渐下降，大型项目不得不面临两个选择：
对仓库/应用进行拆分，采用微前端等复杂技术整合多个子应用。这样固然能够减少每次发布构建的时间，但是会增加开发人力开销。由于影响了项目架构，严重依赖人工，无法大批量复用到多个项目。 提升构建工具的性能，比如用 esbuild 这种原生程序替代 babel 这种 Node 程序，用 Vite 这种 Bundleless 工具替代 webpack-dev-server。相比迁移项目架构，改造构建工具的成本更低，完全可以通过迁移脚本自动化。 这篇文章会介绍和评测当前各种流行的构建工具，从底层库到完整解决方案，帮助大家选择和定制最适合自己的方案。
Bundler
Bundler 是能够通过 import/export 将很多 JavaScript 文件，打包成一个/几个文件的工具。在前端开发中，也经常会 Bundle 其他文件类型，比如 CSS/LESS/SCSS，以及图片和字体。这些部分通常是以 Bundler 插件的形式提供。因此 Bundler 通常是一个平台，可以通过插件来扩展特性。
Webpack 是最流行的 Bundler。Rollup，Parcel 则是后起之秀。以编译器见长的 esbuild 和 swc 也提供了 Bundle 能力，但是插件生态不足。
特性比较
spack 还处在实验阶段，功能缺失非常多，因此不建议在任何实际项目中使用。
esbuild 稍好一些，如果你不需要 CSS Modules，不用代码分割，不需要支持 IE，也不需要输出 UMD，那么 esbuild 是可以满足你的需求的。 对于个人项目来说，这完全是可行的。对于企业项目，esbuild 作为 bundler 显然还不够全面，但它作为编译器和 Rollup 配合使用还是很好用的。
parcel，rollup 和 webpack 是功能最为全面的，能够应对绝大多数前端项目需求。webpack 的插件生态最丰富，兼容性也最好。rollup 和 parcel 则更加轻量化。Parcel 的 UMD 打包格式缺失，不适合用于组件库或微前端构建，但是对普通应用还是够用的。
webpack rollup parcel esbuild spack CSS Modules ✔️ ✔️ ✔️ ✔️ ❌ LESS ✔️ ✔️ ✔️ ✔️ ❌ Sass ✔️ ✔️ ✔️ ✔️ ❌ 代码分割 ✔️ ✔️ ✔️ ❌ ❌ CJS 输出格式 ✔️ ✔️ ✔️ ✔️ ✔️ ESM 输出格式 ✔️ ✔️ ✔️ ✔️ ✔️ UMD 输出格式 ✔️ ✔️ ❌ ❌ ❌
性能比较
测试打包 antd + lodash + react + react-dom + three.js 的速度。为了控制变量，统一采用 esbuild 作为 minifier（spack 不支持除外）。
详细测试数据见 https://github.com/guoyunhe/benchmark-bundlers
webpack rollup parcel esbuild spack ThinkPad T480 5.347s 14.548s 6.069s 0.249s 1.082s MacBook 16, 2019 4.229s 12.790s 5.225s 0.227s 1.012s
esbuild 是用 Go 语言编写，spack（swcpack）是用 Rust 语言编写。两者都编译成二进制文件运行，速度比其他 JS 编写的 Bundler 快几十倍。从 20s 到 0.2s 已经是一个质的飞跃了。
相比之下，传统的 JS Bundler 就慢得多了。令人意外的是，被很多人认为过时了的 webpack 居然比 parcel 和 rollup 更快。尤其是 rollup 的性能，令人意外地差。我们分析是因为 lodash 和 react 都是 CJS 模块，rollup 需要将其转化成 ESM 才能使用，因此比 webpack 慢了一倍多。
综合评价
目前 webpack 仍然是最全面的 Bundler 选择，支持特性最丰富，生态最为庞大。而且它的性能并不差，在应用打包场景要优于 rollup 和 parcel。
而放眼未来，esbuild 的潜力最大。它的性能无与伦比，且具有成熟的插件接口。它的代码分割能力已经在测试中，前途一片光明。甚至 Vite 也希望在 esbuild 成熟之后，移除 rollup 而直接用 esbuild 打包。
JS Minifier
Production 构建需要对 JS 文件和 CSS 文件进行 Minify 处理，让生成的文件更小，加载更快。JS 的 Minifier 包括 terser，esbuild，swc。衡量它们优劣的主要指标是速度和压缩率。
以下测试用 webpack + terser/esbuild/swc 打包和压缩 antd + lodash + react + react-dom+three.js。详情见 https://github.com/guoyunhe/benchmark-js-minifiers
no-minify terser esbuild swc 产物尺寸 4.7MB 1.8MB 1.9MB 1.9MB 运行时间 ThinkPad T480 4.677s 17.046s 5.615s 8.997s 运行时间 MacBook 16, 2019 3.556s 13.834s 4.052s 6.892s
esbuild 和 swc 在速度上大幅度领先 terser。对于这类高计算量任务，Node.js 的性能比原生程序差得多。同为原生程序，esbuild 比 swc 的性能更好，说明它的设计更优秀。而从压缩率上来看，terser 略好于 esbuild 和 swc 但差距不大。因此综合来看，我认为 esbuild 是最佳的 minifier。
JS/TS Compiler
我们在开发中喜欢使用最新的 ES 语法，但在发布时需要兼容旧的浏览器。JSX 和 Vue 文件还包含了特殊语法，即使最新的浏览器也无法识别和运行。因此越来越多的前端项目需要用 JS Compiler 或者叫 Transpiler 来转换源码。这也是一项非常耗时的任务。目前最广泛使用的编译器是 babel，它功能全面，但性能堪忧。而 esbuild 和 swc 则是以速度见长的面向未来的编译器。TypeScript 有自己的编译器 tsc，支持 TypeScript 的类型系统检查，但是它的效率极差。因此 Babel, esbuild 和 swc 都提供了自己对 TypeScript 转译的支持。
特性比较
从特性上来看，babel 仍然是最全面的。esbuild 和 swc 则注重对最新 ES 标准的支持，因此少了对非标准的 JS 修饰器语法（但是支持 TS 修饰器语法）和 Flow 语言的支持。esbuild 不兼容 ES5 和 IE 浏览器，但某些项目仍然有这方面的需求，开发者需要平衡利弊。
babel esbuild swc ES Next ✅ ✅ ✅ ES5, IE11 ✅ ❌ ✅ JS 修饰器语法 ✅ ❌ ❌ Flow 语言 ✅ ❌ ❌ TypeScript 语言 ✅ ✅ ✅ TS 修饰器语法 ✅ ✅ ✅ JSX ✅ ✅ ✅
性能比较
以下测试用 Webpack + babel-loader/swc-loader/esbuild-loader 转译 antd + three.js 源码到 ES5 语法，不进行 minify。详见
babel esbuild swc 运行时间 ThinkPad T480 10.133s 0.464s 0.549s 运行时间 MacBook 16, 2019
综合评价
如果不需要支持 IE11，那么 esbuild 是最好的选择，它的性能非常好。
如果需要支持 IE11，那么推荐 swc，性能接近 esbuild 且浏览器兼容性更好。
只有当 esbuild 和 swc 都无法支持你的项目需求时（比如用到了 JS 修饰器语法），再考虑 babel。babel 虽然功能最为全面，但性能比 esbuild 和 swc 慢几十倍，已经无法支持大型项目了。
Dev Servers
Webpack Dev Server
Webpack Dev Server 的出现，极大提升了 React 应用开发的效率：修改代码时，组件会自动被替换，无需手动刷新，也不会重新加载页面。然而早期的 Webpack 和 Webpack Dev Server 每次修改文件都会重新编译打包，给人越来越慢，又无能为力的痛苦感受。Webpack 5 和 Webpack Dev Server 4 已经在性能方面有了极大的改善。中小型项目的瓶颈大多不是 Webpack 本身造成，而是上面介绍过的 Compiler 和 Minifier。如果结合 swc 和 esbuild，Webpack Dev Server 仍然很能打。
但是在大型应用场景，Webpack Dev Server 还是有不足的。想象一下，你有一个包含几万行代码的 SPA 应用，且没有做代码分割。Webpack Dev Server 会将所有代码编译打包之后才能启动。这样一来，启动速度就会变得很慢。但实际上，我们每次只开发项目中很小的一部分，余下的页面/弹窗等组件并不需要提前编译加载。
但是这也并不是我们一定要抛弃 Webpack Dev Server 理由。大型应用场景，也极少硬着头皮上 SPA，而是用微前端框架将应用做进一步的切分。开发时 Webpack Dev Server 只需要运行子应用即可。
但是如果我们就是要做巨石 SPA 应用呢？在本地开发场景下，可以利用浏览器原生的 ES Module 能力动态地按需加载模块，而不需要编译打包所有内容。这样是不是就可以解决我们上面遇到的那个问题了呢？理论上行得通，但实际效果不尽如人意。
Snowpack
Snowpack 就是这样一个设计。理论上动态加载本地 JS 文件几乎没有延迟。但是这些模块并不都能直接在浏览器中运行。比如有很多 NPM 依赖是 CJS 而非 ESM 模块，我们写的代码有 JSX 和 TypeScript，更不要说还有 Sass，LESS，CSS Modules 这些要处理。因此动态加载每个文件时，都有一定的等待时间，而且无法并行处理。结果是在冷启动过程奇慢。在中小型项目开发中，不及 Webpack Dev Server 有效率。大型项目。而且，它并不能构建部署生产环境，仍然需要使用 Webpack 或 Rollup 来补足，无疑增加了项目维护成本。
因此在实际项目中，很难看到 Snowpack 的身影。Snowpack 本身的开发也陷入了很长时间的停滞不前。不过，Snowpack 的思路被 Vite 和 Parcel 2 所继承并改进，取得了成功。
Vite
Vite 给出了更好的答案：将依赖模块预先用 esbuild 进行 Bundle 以快速加载，项目模块采用 Unbundle 模式动态编译加载。
但是，Vite 对不同前端框架的支持程度是不同的，实际运行效率也差别很大。它的 Vue 插件用 esbuild 编译，速度极快。而它的 React 插件用的是 Babel 编译，速度一般。
另外我们发现，Vite 的缓存校验机制存在比较大的问题。更新 node_modules 中的依赖之后，Vite 缓存并没有更新。在开发过程中只能禁用缓存，这导致开发效率进一步降低。
Parcel 2
Parcel 2 和 Vite 的思路类似，但是有两个重要改进：
缓存范围更广，效率极高，热启动在 1s 内 采用了 swc 而非 babel 编译，构建和刷新速度更快 这两个优势使得 Parcel 2 在几乎各个性能指标上都领先于其他竞争对手。
性能比较
TODO
