持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第3天，点击查看活动详情
此前，发布 Next.js 13 的 Vercel 公司，推出并开源了下一代打包工具：Turbopack。
Turbopack 是由 Webpack 的创建者 Tobias Koppers 和 Next.js 团队共同使用 Rust 编写。
Turbopack 建立在新的增量架构上，以提供最快的开发体验。在大型应用上，它的更新速度比 Vite 快 10 倍，比 Webpack 快 700 倍。在更大的应用上，通常会比 Vite 快 20 倍。
由于 Turbopack 只打包开发所需的最少资源，因此启动时间非常快。在具有 3000 个模块的应用上，Turbopack 需要 1.8 秒即可启动，而 Vite 则需要 11.4 秒：
对此，vite 作者尤雨溪还在推特上和 Matt Kane 发生了争论：
很快，尤雨溪新建了一个名为 vite-vs-next-turbo-hmr 的项目来给 vite 和 turbopack 做了一个 HMR 测试。
该项目主要内容为：
首先，两个项目都是通过以下命令创建的。
npx create-next-app@latest
npm init vite@latest # 选择React预设值
在这两个项目中，分别都有以下几个文件：
genFiles.(m)js 文件在项目中可以生成 1000 个组件。所有组件都被导入根组件（在 Next 中，是根页面组件），并同时渲染。这一步已经完成，文件也已经签入，但该脚本包括在内，供参考。
app/page.js 文件有 'use clien' 指令，为了以确保正确的比较，以客户端模式渲染。因为服务器组件会产生非同小可的 HMR 开销（慢4倍）。
对于每个项目，在一个单独的 Node 进程中运行 watch.(m)js，以获得文件变化的确切时间戳。这被用来标记HMR的开始。
使用 vite 和 next dev --turbo 分别启动项目，然后编辑以下文件来测试 HMR：
- Next：app/page.js（根组件）和 app/comp0.jsx（子组件） 。
- Vite： src/App.jsx（根组件）和 src/components/comp0.jsx（子组件）。
组件都在其输出中渲染 Date.now()。DOM 中最终渲染的时间戳被用来标记 HMR 的完成。
测试环境：
- 记录超过 5 次运行的数据和平均值。
- 时间单位：毫秒。
- 在 M1 MacBook Pro 上进行测试。
测试结果：
| Vite (根组件) | Vite (子组件) | Next (客户端根组件) | Next (客户端子组件) | Next (RSC 根组件) | Next (RSC 子组件) | |
|---|---|---|---|---|---|---|
| 1 | 580 | 179 | 335 | 87 | 782 | 661 |
| 2 | 667 | 177 | 343 | 72 | 912 | 633 |
| 3 | 638 | 183 | 334 | 88 | 922 | 453 |
| 4 | 513 | 180 | 337 | 85 | 829 | 640 |
| 5 | 632 | 140 | 324 | 90 | 737 | 539 |
| 平均值 | 606 | 171.8 | 334.6 | 84.4 | 836.4 | 585.2 |
可以看到，在客户端模式下，Next 的速度要更快，而在 RSC 模式下，Vite 要更快。
