你好。
Next.js 13 已发布。
添加了吸引人的新功能，例如不再需要 a 标签的 next/link 和使用 React 18 的 Suspense 渲染得很好的 app/ Directory。我想尝试新的 Turbopack。
官方文档然后，“对于大规模应用，Turbopack 更新速度比Vite 快10 倍，比Webpack 快700 倍”，所以这是一个合理的能力。我会看看它。
请
我通过尝试一切来加深我的知识，并将其作为个人备忘录输出，以免我忘记它，所以英文解释可能是错误的，或者我可能会说一些奇怪的东西。
如果我错了，请在评论中告诉我，将不胜感激。
为什么 Turbopack 更快
在深入研究 Turbopack 之前，我们想了解 Turbopack 如何在大型应用程序中以比 Vite 快 10 倍和比 Webpack 快 700 倍的速度更新。
文档似乎主要使用関数レベルのキャッシュ和リクエストレベルのコンパイル这两种机制来实现这一性能。我们将逐一查看。
功能级缓存
Turbopack 通过在函数级别执行增量计算来捆绑程序。增量计算意味着每次更新一些输入数据，仅输出取决于更新的数据是重新计算
这似乎消除了不必要的计算，并导致比重新计算所有内容更快的捆绑。
现在，让我们在引用官方文档图的同时遵循具体流程。
现在考虑在您的开发服务器上捆绑api.ts 和sdk.ts。
引用：https://turbo.build/pack/docs/core-concepts
捆绑api.ts 和sdk.ts 时，捆绑器分别捆绑api.ts 和sdk.ts 并将它们连接到一个文件中（图中为fullBundle）。 Turbopack 然后缓存所有调用函数的结果。
现在，假设您添加sdk.ts 并更新sdk.ts。那会发生什么？
引用：https://turbo.build/pack/docs/core-concepts
sdk.ts 已更新，因此 Turbopack 知道接收文件系统事件并需要再次捆绑。
Turbopack 尝试生成一个新的完整包，但关键是 api.ts 没有更新。此时，Turbopack 并没有重新绑定api.ts，而是从之前缓存的缓存中读取出来，传递给concat。
像这样在函数级别进行缓存消除了不必要的重新计算并提高了性能。
在 Turbopack alpha 中，缓存存储在内存中。看起来计划是将来将此缓存存储在远程缓存中。详细的，我想在“Turbopack 的未来”的理论中介绍一下。
请求级编译
在 Next.js 11 及更早的版本中，在启动开发服务器时，整个应用程序被编译然后显示。似乎
逐页编译感觉已经足够好，但与 Vite 这样的框架相比，感觉并不完美。
这是因为Vite在开发模式下使用的是Native ESM，而Native ESM不做任何捆绑，所以只加载视图真正需要的。
在逐页编译中，所有隐藏在视图中的模块和页面代码都被读取和捆绑，所以执行速度比Vite这样也使用Native ESM的框架要快，我要输了。
Turbopack 与 Native ESM 一样，只计算渲染页面所需的代码并将其发送到浏览器。
为什么 Turbopack 比 Vite 快
为什么 Turbopack 比 Vite 快？根据文档，不使用 Native ESM 和不使用 esbuild 似乎是相关的。
如前所述，Vite 在开发模式下使用的是 Native ESM。与 Native ESM 一样，Turbopack 只计算页面渲染所需的代码并将其发送到浏览器，因此乍一看似乎是在做同样的事情，但在应用程序中似乎有些不同。
Vite 使用本机 ESM 将代码发送到浏览器而不捆绑它。由许多模块组成的大型应用程序会产生大量的链式网络请求，导致启动时间相对较慢。
Turbopack 在不使用 Native ESM 的情况下捆绑然后发送，对于具有许多模块的大型应用程序来说似乎更快，因为它不会在链中生成大量网络请求。
此外，不使用 esbuild 似乎也有不小的贡献。Vite 在内部使用 esbuild 执行许多任务。 esbuild 是一个非常快速的打包工具，但不做太多缓存。
正如前面在函数级缓存部分所讨论的，我们相信基于 Rust 的 Turbopack 凭借其积极的缓存和避免不必要的计算，将允许开发团队在大型应用程序中表现得比 esbuild 更好。似乎是这样。
试试 Turbopack
现在我对 Turbopack 有了一定的了解，我想从这里开始实际使用 Turbopack。目前 Turbopack 只能与 Next.js v13 一起使用，因此我们将使用 Next.js v13 创建一个由 vercel 提供的新教程项目。
$ npx create-next-app --ts --example with-turbopack
转到创建项目的根目录并执行npm install npm run dev。
只有这个。这将使用 Turbopack 启动开发服务器。
启动速度非常快
我在教程中接触到的印象
由于每次转换都捆绑，延迟有点烦人
这是不可避免的，但每次屏幕转换时都会出现大约 100 毫秒到 500 毫秒的延迟。
我想知道为什么我担心在 Next.js 12 的页面转换过程中会出现 100ms 到 500ms 的延迟，但也许这在 Next.js 12 的右下方显示是因为它没有了。
我希望它在加载时显示。
有些按钮有时不响应
我不知道为什么，但有时会出生一个没有响应的按钮。如果您移动到另一个页面或打开开发工具，您将能够单击它，因此似乎存在某种错误。我不确定如何重现它，所以...
如果在测试版中改进它会很好。
Turbopack 的未来
最后，作为 Turbopack 的未来，我想介绍一下文档中描述的有趣的远程缓存。
目前在 alpha 版本中，Turbopack 将函数级缓存存储在内存中，但未来有计划将其存储在文件系统中并持久化。
成功保存到文件系统后，下一步就是实现对远程缓存的持久化。
将来，您将能够使用 Vercel 远程缓存在团队内共享功能级缓存。
能够进行远程缓存意味着花费不必要的长时间的生产构建也可以显着提高性能这意味着。
或许内容量大的 SSG 构建的性能可能会得到很大提升。
（对于像Jamstack这样配置的web应用，需要调用Turbopack的API才能知道内容，但是如果你真的想在SSG期间大大提高构建性能，获取没有变化的内容。我不'认为我不应该，因为那样我将不得不准备一个枚举更改内容的端点......这似乎有点麻烦。）
概括
在这篇文章中，我总结了 Next.js 13 的新特性 Turbopack 的机制，并简要尝试了 Turbopack。
它被宣传为比 Vite 快 10 倍，所以一开始我以为 Vite 会过时，但我不这么认为。对于小应用来说确实在误差范围之内，而且我认为它可以与大应用很好地共存，因为差异只有几秒钟。
但是，我个人认为 Next.js 能够脱离 webpack，这是一件了不起的事情。从现在开始，我似乎可以过上依赖 Vercel 的生活。
嗯，结束了。
参考
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308631845.html