下一代前端构建工具

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 的成熟度,因此完全没有可比性。目前只能关注,深入分析或评测意义不大。


📅

📁

🏷️

评论

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据