上周整理了Turbopack发布后各方的反应，以便我和同学们在接下来的决策中参考步。然后忙碌的一周过去了，发现这周博客没更新，赶紧补上。TL;DRTurbopack的slogan更像是“宣传”，实际效果提升并没有那么大。Turbopack目前只支持Next.js+React，并没有建立完善的插件机制，所以完全没有生态。如果我们的主要开发环境不一致，可能暂时用不上。Turbopack是基于Rust开发的，性能的提升主要来自于SWC，所以如果你有时间和兴趣，可以直接使用SWC来代替编译工具。建议非目标开发人员团体暂时忽略迁移。Turbopack在封装工艺上做了很多改进，值得持续关注。如果你每天都使用React并且希望在新技术出现时抢占先机，那么早点开始是好的。2022-10-26首先，10月26日，Vercel发布了Turbopack，自称是Webpack的继承者，号称比Wepback快700倍，比Vite快10倍。这些是官方推送的亮点：~700xfasterthanWebpack->700timesfasterthanWebpack10xfastthanVite->10timesfasterthanViteNativeincrementalarchitecturebuiltwithRust->BasedonRust,withanativescalablearchitectureSupportforReactServerComponents->SupportforReactservercomponentsSupportforTS,JSX,CSS&more->SupportforTS,JSX,CSS,andmore官方推送：https://twitter.com/vercel/st...Official网址：https://vercel.com/blog/turbo...友达的观点非常快，Vite作者@youyuxi跟进表示反驳：“比Vite快10倍”并不完全准确”'10x比Vite快的速度并不完全准确，”他说。然后他进一步介绍了他的理由：Vite默认的ReactHMR仍然是基于babel的，而Next/turbopack使用的是基于swc/rust的transform，所以HMR的性能差异有点像苹果和橘子。因为Vite默认的ReactHMR仍然是基于Babel，而Next/Turbopack使用的是基于Rust平台的SWC，所以这里HMR的性能差异是关公和秦琼（这个帖子背后有几个原因，我就不翻译了一个接一个）：如果有必要，Vite可以切换到swc/rust转换，我们目前选择不这样做，因为将swc添加到deps列表是额外的重量，即使没有它HMR也足够快。如果有必要，Vite当然可以切换到swc/rust，但是Vite开发团队并不想这样做，因为即使只有Babel，HMR也足够快（而事实并非如此）。用SWC替换Babel只会增加开发负担。turbopack确实解决了Vite在大型应用上的请求拥塞问题。在Vite方面，我们也在探索如何通过即将推出的浏览器功能（如webbundles）来解决这个问题。我们Vite团队也在探索如何解决这个问题，比如能否使用即将推出的浏览器功能（WebBundles）。从长远来看，我们还可以考虑在引擎盖下使用turbopack来替换esbuild/Rollup（如果合适），因为它具有强大的缓存功能。替换esbuild/Rollup。如果合适的话。我很高兴Vercel正在将其资源投入到webpack的合适的原生速度继承者中（这是应该的），并且我们在Vite上的工作推动了这一切的发生。看看它是如何演变的将会很有趣——我希望它可以真正成为框架不可知论者，而不是Next-first。我很高兴Vercel愿意投入资源来构建Webpack的继任者并专注于提高他们的速度性能（这是应该的），而我们在Vite上的努力已经达到了这个目的。我对它们在未来如何发展很感兴趣——我希望它不会与框架捆绑在一起，而不是Next-first。SeanLarkin的观点（SeanLarkin是Webpack的核心团队成员。目前似乎在LinkedIn工作。)SeanLarkin也表达了他的观点：很少有想法：喜欢创新，但它看起来适度SWC权力，希望那里有更多的标注。对这与next/turborepo的纠缠感到失望。但是Vercel需要做。平均用户从webpack迁移的路径将是艰难的。我喜欢开发服务器仍然捆绑模块，因为ESM比原始ESM慢。我需要剥离更多的层来尝试让一个独立的实现工作。这一切都在alpha中，所以我们仍然需要看更广阔的视野，但我希望我们的销售量减少，我喜欢创新。但是好像Turbopack更多的是借鉴了SWC，希望对方能表达清楚。我对Turborepo与Next的联系感到失望。但是Vercel需要赚更多的钱（天使投资），没办法。普通用户迁移到Webpack会非常困难。我的偏好是开发服务器上的模块仍然被打包，因为ESM比原来的ESM慢。我需要剥离更多层才能使独立实现正常工作。目前还在alpha阶段，还得稍微观察一下，不过还是希望销售人员少点轻狂，开发完成。2022-10-27到2022-10-28这期间，@youyuxi觉得Turbopack的数据有问题，因为Vercelbenchmark的设计有问题，于是尝试调整测试方法并给出了一些数据。不过，他后来删除了这些推文，因为数字不正确。2022-10-27Vite的核心成员之一，@antfu7在知乎上发表了自己的看法：他认为Vite的插件系统和建立在其上的生态系统更具吸引力。这将很快为其他领域带来改进。至于Turbopack，拭目以待。https://zhihu.com/question/56...如何评价Vercel开源的Turbopack用Rust实现？–AnthonyFu的回答–知乎2022-10-29经过几天的实验，Vite作者@youyuxi发布了一条新推文，在进一步比较Turbopack和Vite的性能后，介绍了他的新结论。我通过使用swc将Reactrefresh转换为vite来更新vitevsnext/turbo基准测试。为了避免混淆，我已经删除了之前两条过时数字的推文。最新数字：root：vite338.2ms/next334.6msleaf：vite141.8ms/next84.4ms我重新评估后更新了VitevsNext/Turbopack的基准测试使用Vite+SWC进行React转换。为了避免混淆，我删除了前两条带有过时数字的推文。最新比较数字：Root:Vite338.2ms/Next334.6msLeaf:Vite141.8ms/Next84.4msswctransform在根组件的情况下帮助很大，因为文件很大，之前仅在babeltransforms中就花费了300ms。这使得vite的速度几乎与turbopack完全相同。当涉及到根组件时，SWC转换有很大帮助。由于文件太大，过去仅在Babel中转译就需要300毫秒。更换后，Vite的速度几乎和Turbopack完全一样。有趣的是，在叶子场景中，turbopack的速度仍然快了69%——这意味着随着文件变大，ViteHMR实际上赶上了turbopack，可能在更大的应用程序中扩展得更好。有趣的是，在叶子场景中，Turbopack仍然更快，提升了约69%。-这意味着随着文件变大，ViteHMR实际上可以赶上Turbopack，并可能在更大的应用程序中更好地扩展。用于测试的存储库：https://github.com/yyx990803/...因为我们现在正在使用相同的一组转换测试相同框架的HMR，与之前发布的数字相比，结果与其他框架的相关性更高。现在，由于我们使用同一组转换测试同一框架的HMR，因此结果比之前公布的数字更相关。只是为了添加一点上下文——在这个基准测试中，即使在使用swc进行React转换之前，turbo也只是vite的2倍（与市场上的10倍相比）。所以一开始的区别并没有那么大。前提：这个基准测试，即使在用SWC替换React之前，Turbo也只会比Vite快2倍（他们在市场上声称快10倍）。所以实际上，差异一直都没有那么大。2022-10-31及之后，本文正文编译于10月31日。之后@youyuxi还在孜孜不倦地跑标杆，与各种支持者、反对者、吃瓜群众讨论或争论。但是他的观点并没有太大的改变，我就偷懒不翻译了。相信大家看了之后都能做出自己的判断。N大神有一些看法，摘录在这里：vite为了提高速度，利用浏览器的特性，在dev阶段使用esbuild将esm包预编译到浏览器，不打包，使用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平台。
