2022 年，Webpack + Babel + Terser 仍然是前端项目构建工具的主流，广泛用于各种生产环境。不可否认，Webpack 和 Babel 仍然在持续进化，对各类研发提供了最稳定且全面的支持。但是随着前端项目规模的增长，CI 流水线的普及，构建性能问题已经成为了影响开发效率的一个关键因素。下一代构建工具，试图从不同的角度实现对构建效率的提升。
esbuild
用 Go 语言实现的构建工具，提供了编译，打包，压缩能力。由于是原生程序，且几乎不依赖第三方库，充分利用 CPU 多核架构等原因，esbuild 实现了夸张的毫秒级编译速度，效率数百倍于 Webpack + Babel。
优点：
- 高性能。目前最快的实现，整体上略优于 swc。
- 低占用。Go 语言对字符串的内存优化很好，即使采用多线程工作方式，内存占用仍然远低于基于 Webpack 的工具。
缺点：
- 自身不提供 HMR，需要依赖其他工具实现。
- 不支持 React Refresh，对 React 的 HMR 不能用 webpack-dev-server + esbuild 编译的方案。
- 产物代码分割功能仍处在实验阶段，相比 Webpack 和 Rollup 还是比较简单，不太可靠。
- 插件生态不健全。
适用场景：
- 纯 JS 库构建。不需要 HMR，只需要 watch 能力。
- Node.js 后端应用构建。不需要 HMR，只需要 watch 能力。
- Jest 和 SSR 等 Node 运行环境的代码转译。
- 嵌入其他构建工具。比如 Vite 用了 esbuild 的编译和压缩能力，不足的部分用 Rollup 插件体系和自己实现的 HMR 补全。
swc
用 Rust 语言实现的构建工具，swc 实现了编译和压缩能力，swcpack 实现了打包能力（实验性）。swc 设计之初就是完全对标 Babel 的，相比 esbuild 拥有更广泛的适用场景。
优点：
- 高性能。实际测试略慢于 esbuild，但也比 webpack+babel+terser 快上几十倍。
- 支持 React Refresh。这一点是对 esbuild 的巨大优势，且短期内 esbuild 无法克服的问题。
缺点：
- 自身不提供 HMR，需要依赖其他工具实现。
- 打包能力还是实验性质，缺乏高级配置支持。
- 插件生态不健全，用 Rust 编写插件门槛较高。
适用场景：
- 纯 JS 库构建。不需要 HMR，只需要 watch 能力。
- Node.js 后端应用构建。不需要 HMR，只需要 watch 能力。
- Jest (@swc/jest) 和 SSR 等 Node 运行环境的代码转译。
- 嵌入其他构建工具。比如 Parcel 用了 swc 的编译和压缩能力，不足的部分用自己实现的 HMR 补全，并有 Parcel 自己的插件体系。
Vite
基于 esbuild 的编译和压缩能力，Bundleless 的 HMR 实现，并用 Rollup 插件生态补足了常用的打包特性。目前性能和特性综合考量的最佳选择。
更早的 Bundleless 实现 Snowpack 已经泯然众人了。Bundleless 最大的问题在于，现在前端应用的依赖树太深太广，模块文件太多，逐个文件加载导致启动速度极其缓慢。而 Vite 则是融合了 Bundle 和 Bundleless 两种策略，对 node_modules 还是用 esbuild 去快速 bundle，一次性加载，对于源码再采用 bundleless 策略。这样就平衡了启动速度和热加载速度。
优点：
- 构建速度更快
- 热更新速度更快
- 能够使用众多的 Rollup 插件
缺点：
- 由于 esbuild 不支持 React Refresh，React 项目还是要走 Babel，一定程度上拖慢了速度。
- Rollup 及其插件生态还是以 JS 为主，性能优化空间有限。Vite 作者寄希望于 esbuild 打包能力和插件生态成熟，用 esbuild 替换掉 Rollup。
适用场景：
- Web 前端应用
- 浏览器插件
- Electron 应用
- 小程序
Parcel 2
Parcel 基于 swc 并有自己的 HMR 和插件生态。设计上与 Vite 类似，但 Parcel 自研部分更多，而 Vite 依赖且受限于 Rollup。性能上 Parcel 甚至更快一些，尤其是缓存性能，热启动极快。但在稳定性上 Parcel 控制的并不好，一个最简单的 React 应用都需要一些 hack 才能工作。
优点：
- 构建速度快
- 缓存效率高
- 热更新速度快
缺点：
- 不兼容 pnpm
- 插件生态不足
适用场景：
- Web 前端应用
- 浏览器插件
- Electron 应用
- 小程序
Turbopack(Alpha)
用 Rust 实现 Webpack 替代，工作原理和 Webpack + Webpack Dev Server 保持一致，而没有走时下流行的 bundleless 路线。当项目源码（不包括 node_modules）文件数量达到数千，Vite 启动速度会随文件数量降低，即使本地几乎不存在网络延迟，数以千计的 HTTP 请求以及代码转译任务仍然耗时不菲。而 Turbopack 则通过提升打包性能，在保持 Webpack 工作方式的情况下，实现了快速启动和 HMR。当前 Turbopack 的测试性能是领先 Vite 的。
假如 Vite/Parcel 也用 Rust/Go 完全重写，那么 Vite/Parcel 和 Turbopack 应该具有以下关系：
- 在文件数量小于 N 时，Vite/Parcel 的冷启动速度更快，但是 Turbopack 也足够快。
- 在文件数量大于 N 时，Turbopack 的冷启动速度更快，且于 Vite/Parcel 的差距越来越大。
- Vite/Parcel 的 HMR 速度总是快于 Turbopack，但是两者都足够快，以至于差异肉眼无法分辨。
可惜 Turbopack 目前并没有推出正式版本，完全没有达到 Vite/Parcel 的成熟度，因此完全没有可比性。目前只能关注，深入分析或评测意义不大。
发表回复