尤雨溪：Turbopack真的比Vite快10倍吗？

,大家好，我是 CUGGZ。,10 月 25 日，Vercel 推出了下一代打包工具：Turbopack，它是基于 Rust 的 Webpack 继任者，其文档中提到，Turbopack 比 Vite 快 10 倍。11 月 1 日，Vue、Vite 作者尤雨溪发表文章 《Is Turbopack really 10x Faster than Vite?》，对 Turbopack 和 Vite 进行了测试对比，下面就来看看详细内容吧！,在 Turbopack 官方文档的基准图中，最初显示带有 Turbopack 的 Next 13 能够在 0.01 秒内执行 React Hot-Module Replacement (HMR，即热更新)，而对于 Vite，则需要 0.09 秒。上面也有冷启动性能基准，但由于没有一个冷启动基准显示出 10 倍的优势，我们只能假设“快 10 倍”的说法是基于 HMR 性能。,Vercel 并没有在文档中包含指向他们用来生成这些结果的基准的任何链接。所以，尤大决定使用新发布的 Next 13 和 Vite 3.2 来验证这些声明。测试的要点是通过测量以下两个时间戳之间的增量来比较 HMR 性能：,该基准还测量了两种不同情况下的结果：,在测试这些之前，还有一些额外的细微差别值得一提：,Next 13 引入了一个重大的架构转变，现在的组件默认为服务端组件，除非用户使用“use client”指令明确选择客户端模式。它不仅是默认设置，Next 文档还建议用户尽可能保持服务端模式，以提高最终用户的性能。,最初的基准测试是在服务端模式下使用根组件和叶子组件测量 Next 13 的 HMR 性能。结果表明，Next 13 在两种情况下实际上都较慢，并且对于叶子组件而言差异显著，测试方法和测试结果如下。,已编辑的组件都在其输出中包含 Date.now()。DOM 中最终渲染的时间戳用于标记 HMR 的完成。,,有人指出，应该在没有 RSC（React 服务端组件）的情况下对 Next 组件进行基准测试以使其相等。因此，在 Next 根组件中添加了“use client”指令以选择客户端模式。事实上，在客户端模式下，Next HMR 显着改进，比 Vite 快 2 倍，测试方法和测试结果如下。,,我们的目标是让基准只关注 HMR 性能差异，所以需要消除另一个变量：Vite 的默认 React 预设使用 Babel 来转换 React HMR 和 JSX。,React HMR 和 JSX 转换不是与构建工具耦合的特性，它可以通过 Babel（基于 JavaScript）或 SWC（基于 Rust）来完成。Esbuild 也可以转换 JSX，但缺乏对 HMR 的支持。SWC 比 Babel 快得多（单线程时快 20 倍，多核时快 70 倍）。Vite 目前默认使用 Babel 的原因是安装大小和实用性之间的权衡。SWC 的安装量相当大（node_modules 中有 58 MB，而 Vite 只有 19 MB），并且许多用户仍然依赖 Babel 进行其他转换，因此 Babel 对他们来说是不可避免的。但是，这种情况在未来可能会发生改变。,Vite core 并不依赖 Babel，因此使用 SWC 而不是 Babel 来处理 React 转换不需要在 Vite 中进行任何更改，只需将默认的 React 插件替换为 vite-plugin-swc-react-refresh。切换后可以看到，Vite 在根组件中有显着提升，赶上了 Next：,,有趣的是，这里的增长曲线显示 Next/turbo 在根组件比叶子组件中慢 4 倍，而 Vite 只慢 2.4 倍。这意味着 Vite HMR 在更大的组件中可伸缩性更好。此外，切换到 SWC 还可以改善 Vite 在 Vercel 基准测试中的冷启动指标。,由于这是一个涉及 Node.js 和原生 Rust 部分的复合基准测试，因此在不同的硬件上会有很大差异。以上结果是在 M1 MacBook Pro 上收集的。其他用户在不同的硬件上运行相同的基准测试并报告了不同的结果。在某些情况下，Vite 在根组件情况下更快，而在其他情况下，Vite 在两种情况下都明显更快。,在尤大发布了自己的基准后，Vercel 发布了一篇博客文章，阐明了他们的基准方法，并将他们的基准提供给公众验证。阅读文章和基准代码后，以下是一些关键点：,总而言之，如果以下所有条件都成立，“比 Vite 快 10 倍”的说法是成立的：,如果我们要比较的是“开箱即用的默认设置”，那么我们应该与 Next 中启用的 RSC 进行比较，因为这是默认设置，也是 Next 积极鼓励用户使用的。由于 Vercel 的基准测试没有使用 RSC，并且正在测量“模块评估时间”，以排除 React 的 HMR 运行时引起的差异，因此可以公平地假设基准测试的目标是对 Vite 和 Turbopack 固有的 HMR 机制进行比较。,不幸的是，在这个前提下，Vite 仍然在基准测试中使用 Babel 使这个对比是不平等的。在 Vite 中使用 SWC 进行转换更新对比结果之前，Turbopack 比 Vite 快 10 倍的结论是不准确的。,此外，我相信大多数人都会同意：,作为 Vite 的作者，很高兴看到像 Vercel 这样资金雄厚的公司在改进前端工具方面进行了大量投资。在适用的情况下，甚至未来可能在 Vite 中利用 Turbopack。然而，开源工具的竞争应该建立在公开沟通、公平比较和相互尊重的基础上，令人失望和担忧的是，看到激进的营销使用了精心挑选的、未经同行评审的、边缘误导性的数字，这些数字通常只在商业竞争中出现，相信 Vercel 可以做得更好。