共计 5165 个字符，预计需要花费 13 分钟才能阅读完成。
上周整顿了一下 Turbopack 公布后的各方反馈，以便让本人和各位同学下一步做决策的时候能有所参考。接着繁忙的一周过来，我发现博客这周还没更，于是连忙来补一下。
TL;DR
- Turbopack 的宣传语更多还是“宣传”，实际效果晋升并没有那么微小。
- Turbopack 目前只反对 Next.js + React，且没有建立健全插件机制，所以没有生态可言，如果咱们的次要开发环境不统一，可能临时用不到。
- Turbopack 基于 Rust 开发，性能晋升次要来自 SWC，所以有工夫、有趣味的话，间接应用 SWC 替换编译工具就好。
- 非指标开发者群体倡议先不思考迁徙。
- Turbopack 对于打包过程有不小的改良，值得继续关注。
- 如果你日常应用 React，且想在新技术呈现时斩获先机，早点入手也挺好。
2022-10-26
首先，10 月 26 日，Vercel 公布了 Turbopack，自命 Webpack 继任者，号称速度比 Wepback 快 700 倍，比 Vite 快 10 倍。
这些是官推亮点：
- ~700x faster than Webpack -> 比 Webpack 快 700 倍
- 10x faster than Vite -> 比 Vite 快 10 倍
Native incremental architecture built with Rust -> 基于 Rust，具备原生可增长架构
- ◆ Support for React Server Components -> 反对 React 服务器组件
- ◆ Support for TS, JSX, CSS & more -> 反对 TS、JSX、CSS，以及更多
- 官推：https://twitter.com/vercel/st…
- 官网：https://vercel.com/blog/turbo…
尤大观点
很快，Vite 作者 @youyuxi 就跟进表白反驳：
“10x faster than Vite”isn’t entirely accurate
“‘比 Vite 快 10 倍’并不齐全精确”，他说。
而后他进一步介绍了本人的理由：
Vite’s default React HMR is still babel-based, while Next/turbopack use swc/rust-based transform, so the HMR performance difference is a bit of apples to oranges.
因为 Vite 默认的 HMR 依然基于 Babel，而 Next/Turbopack 应用的是基于 Rust 平台的 SWC，所以这里 HMR 的性能差别是关公战秦琼（这个 thread 前面还有若干理由，我就不一一翻译了）：
Vite can switch to the swc/rust transform if necessary, we currently chose not to do that because adding swc to the deps list is extra weight, and even without it HMR is fast enough.
Vite 当然能够在必要时切换到 swc/rust，但 Vite 开发团队并不想这样做，因为即便只用 Babel（不那样做），HMR 也足够快。应用 SWC 替换 Babel 只是平添开发累赘。
turbopack does address Vite’s request congestion issue on large apps. On Vite side we are also exploring how we can solve this via upcoming browser features like web bundles.
Turbopack 的确解决了 Vite 在大型利用上的申请拥塞问题。咱们 Vite 团队这边，也在摸索如何解决这个问题，比方，是否能够借助行将推出的浏览器性能（Web Bundles）。
In the long run we may also consider using turbopack under the hood to replace esbuild/Rollup (where suitable), due to its strong caching capabilities.
从久远来看，因为 Turbopack 弱小的缓存能力，咱们也会思考在底层应用 Turbopack 来替换 esbuild/Rollup。如果适合的话。
I’m glad vercel is investing its resources into a proper native-speed successor to webpack (as it should), and that our work on Vite has pushed this to happen. It’ll be interesting to see how it evolves – my hope is it can be made truly framework agnostic, not Next-first.
我很快乐 Vercel 违心投入资源，打造 Webpack 的继任者，并着力晋升它们的速度体现（应该如此），咱们在 Vite 上的致力也达到了这样的目标。我对它们将来的演变很感兴趣——我心愿它不要和框架捆绑在一起，不要 Next-first。
Sean Larkin 观点
（Sean Larkin 是 Webpack 的外围团队成员。目前如同在 LinkedIn 工作。）
Sean Larkin 也表白了本人的观点：
Few thoughts: 几点想法：
- Love the innovation but it looks moderately SWC powers and wish there was some more callout there.
- Disappointed how entangled this is with next/turborepo. But Vercel needs to make.
- The path of migration from webpack for the avg user will be hard.
- I like that the dev server is still bundling modules because ESM slower than raw ESM. I need to peel back more layers to try and get a standalone implementation working.
- It’s all in alpha so we need to still look at the broader view but I hope we’re selling less going fwd
- 我喜爱翻新。但看起来，Turbopack 更多是借力于 SWC，心愿对方能表白得分明一些。
- 我对 Turborepo 与 Next 的绑定水平感到悲观。然而 Vercel 须要挣到更多的（天使资金），没方法。
- 普通用户想 Webpack 迁徙过来，会很艰巨。
- 我偏向于开发服务器上的模块依然是打包后的，因为 ESM 比原始 ESM 慢。我须要剥离更多层，能力让独立的实现工作。
- 目前它还处于 alpha 阶段，所以咱们要看开一点，但我依然心愿，销售手段少一些，好好干开发。
2022-10-27 ～ 2022-10-28
这段时间，@youyuxi 感觉 Turbopack 的数据有问题，因为 Vercel benchmark 的设计有问题，于是他尝试调整测试形式，给出了一些数据。不过起初他删除了这些推文，因为数字不太对。
2022-10-27
Vite 核心成员之一，@antfu7 在知乎上表白了本人的观点：
他认为 Vite 更吸引人的是其插件零碎，和构建在下面的生态系统。这样能力将改良疾速带给其余畛域。Turbopack 方面，静观其变吧。
https://zhihu.com/question/56…
如何评估 Vercel 开源的应用 Rust 实现的 Turbopack? – Anthony Fu 的答复 – 知乎
2022-10-29
通过几天试验，Vite 作者 @youyuxi 发表了新的推文，新推文介绍了他进一步比拟 Turbopack 和 Vite 之间性能之后，失去的新论断。
I updated the vite vs next/turbo benchmark by using swc to transform React refresh for vite. To avoid confusion, I have deleted the previous two tweets with outdated numbers.
Latest numbers:
- root: vite 338.2ms / next 334.6ms
- leaf: vite 141.8ms / next 84.4ms
我通过搭配 Vite+SWC，从新评测 React 转换之后，更新 Vite vs Next/Turbopack 的基准测试。为防止混同，我删除了前两条带有过期数字的推文。
最新的比照数字：
根：Vite 338.2ms / Next 334.6ms
叶：Vite 141.8ms / Next 84.4ms
The swc transform helps a lot in the root component case because the file is big, and previously cost 300ms in babel transforms alone. This makes vite almost exactly the same speed with turbopack.
SWC 转换在根组件时候提供了很大帮忙。因为文件很大，以前仅在 Babel 中转换就要破费 300 毫秒。替换之后，Vite 的速度简直与 Turbopack 完全相同。
Interestingly, in leaf scenarios turbopack is still 69% faster – this entails that Vite HMR actually caught up with turbopack as the file gets bigger, potentially scaling better in larger apps.
乏味的是，在叶子场景中，Turbopack 的速度依然更快，晋升约有 69%。——这意味着随着文件变大，Vite HMR 实际上赶上了 Turbopack，在较大的应用程序中可能会有更好的扩展性。
测试用仓库：https://github.com/yyx990803/…
Because we are now testing the HMR of the same framework with the same set of transforms, the result is more relevant for other frameworks compared to previously posted numbers.
当初，因为咱们应用雷同的转换集测试同一框架的 HMR，与之前公布的数字相比，后果的相关度更高。
Just to add a bit of context – in this benchmark, even before using swc for React transforms, turbo is only 2x compared to vite (compared to marketed 10x). So the difference wasn’t that drastic to begin with.
顺便讲点相干前提：这套基准测试，甚至在替换应用 SWC 转换 React 之前，与 Vite 相比，Turbo 也会仅 2 倍（他们市场声称要快 10 倍）。所以其实始终以来，差别都没有那么大。
2022-10-31 及之后
本文主体整顿于 10 月 31 日，之后 @youyuxi 还在手不释卷的跑 benchmark，与各路反对、拥护、吃瓜者或探讨或争执。然而他的观点变动不大，所以我也就偷懒不持续翻译了，置信大家看完都能做出本人的判断。
N 神有一些观点，摘录于此：
vite 为了晋升速度，利用了浏览器的个性，在 dev 阶段不打包而用 esbuild 预编译 esm 小包投送给浏览器，在 build 时候用 rollup 再打包。这样 dev 就会十分快 (因为无需打包)，但写插件就很决裂，要思考 dev 和 build 两种状况。并且实践上如果依赖小包过多会必定会遇到浏览器并发瓶颈减慢速度。
按 Turbopack 的说法，他 dev 和 build 同样走打包流程，还能比 vite 快，那么铁定是更好的。只是太晚期了，当初还没有凋谢插件生态。而且自命 webpack 继任者没故障，看 github 上就是 webpack 作者主力搞的。
但另一方面如果将来 non-bundler 成为支流，前端不再须要打包。turbopack 就没用了。vite 摈弃 rollup，build 也走 dev 流程就更美了。
https://twitter.com/nshen121/…
SWC 作者和 Webpack 作者
这二位目前都在 Vercel 工作，可能受公司公关限度，都只转发了官推，并没有发表更多意见。
总结
Turbopack 可能不如官网所说的那么好。它确实带来了 HMR 的晋升，但代价是不健全的插件机制和生态环境，以及难以被前端团队把握的 Rust 平台。
将来一段时间，咱们还要持续保持在 Vite 平台上。
