前端技术演化史

Turbopack

Properties1
tags工程化, turbopack, rust, 增量计算, 打包器, vercel

7分钟阅读

🦀 Turbopack

一句话定性

这是 Webpack 作者 Tobias Koppers 的”自我革命”:用 Rust 重写一个打包器,作为 Webpack 的接班人。核心武器是增量计算(incremental computation)——只重算真正变化的部分,把缓存做到函数调用级别。它由 Vercel 主导,深度绑定 Next.js,与 Vite、Rspack 在 Rust 打包器赛道上正面竞争。

一、它是什么 & 出现的时代

Turbopack(2022,Vercel)是一个用 Rust 编写的打包器,被定位为”Webpack 的接班人”。

它最有故事性的一点:操刀者正是 Webpack 的作者 Tobias Koppers。一个人写了统治十年的 Webpack,又亲手用 Rust 写它的继任者——这本身就是对”JS 写的打包器性能触顶”这件事的最权威承认。它诞生在 2018-2023 工程化时代 末期,Rust/Go 工具链潮流的高峰。

二、为什么会出现(解决上一代什么痛点)

既要 Vite 的快,又要 Webpack 的强

  1. Webpack 慢且性能触顶:JS 实现,大型应用 dev 冷启动和 build 都慢。
  2. Vite 的 no-bundle 在超大型应用有代价:Vite dev 不打包,模块极多时首屏请求数会爆;且 dev(esbuild)/prod(Rollup)两套引擎行为不一致。
  3. Next.js 需要一个自己掌控的、能 scale 到超大代码库的工具:Vercel 要为 Next.js(尤其是 RSC、大型企业应用)提供既快又强、且自己能深度优化的构建底座。

Turbopack 的目标:用 Rust 拿到原生性能,用增量计算做到”无论项目多大,只为变化付出代价”。

三、核心机制 & 为什么(可能)流行

核心是增量计算 + Rust 原生性能

① Rust → 原生性能 和 esbuild(Go)、SWC(Rust)同一逻辑:编译型语言 + 真正的多线程并行,远超 JS 实现。Turbopack 内部就用 SWC 做转译。

② 增量计算引擎(Turbo engine / 函数级缓存) 这是 Turbopack 最核心、最与众不同的地方。它把整个构建建模成一张函数调用的依赖图,每个函数的输入输出都被缓存。当你改动一处:

改动一个文件
   │  增量引擎对比:哪些被缓存的函数的【输入】真的变了?
   ▼
只重新执行【输入变了】的那些函数
   │  其余全部命中缓存,直接复用上次结果
   ▼
理论上:重算量只与"改动影响范围"成正比,与项目总大小无关

这套思想类似”为构建过程做了一个精细的 memoization(记忆化)层”。目标是恒定的、极快的增量更新——无论代码库多大,改一行的代价都很小。

③ 按需编译(类似 Vite 的懒思想) dev 时也只编译当前页面/请求真正需要的部分,而不是整个应用。

为什么可能流行:它是 Next.js 的默认/内置构建器——靠 Next.js 庞大的用户基数,天然拥有渠道。再加上 Webpack 作者的背书和”平滑接班 Webpack”的定位。

四、带来的新问题 / 副作用

强绑定 + 不够开放

  1. 与 Next.js / Vercel 深度绑定:它首先服务于 Next.js,作为通用、独立打包器的成熟度和生态远不如 Vite 开放。
  2. 成熟度与稳定性:作为后来者,长期处于 beta/逐步稳定阶段,边缘场景的兼容性和插件生态还在补齐。
  3. 增量缓存的复杂性:函数级缓存极其强大,但也意味着缓存失效逻辑复杂,出问题时调试门槛高。
  4. 生态护城河不深:Webpack 的 loader/plugin 生态它无法直接继承(Rspack 在兼容 Webpack 配置上反而更有优势)。

五、为什么会衰落 / 现状(它还年轻)

Turbopack 不是”衰落”,而是仍在”证明自己”的阶段。

现状(2026)与竞争格局:

工具阵营语言定位/打法
TurbopackVercel / Next.jsRust增量计算 + 深绑 Next.js
Vite社区 / 尤雨溪JS+Go(→Rust)no-bundle dev,生态最广
Rspack字节Rust兼容 Webpack 配置,平滑迁移
RolldownVite 团队Rust重写 Rollup,统一 Vite dev/prod
  • Turbopack 的护城河是 Next.js 的渠道;Vite 的护城河是开放生态;Rspack 的护城河是 Webpack 兼容。三方在 Rust 打包器赛道上各有侧重。
  • 整个赛道的共识已经形成:底层打包器必须用 Rust 写,且要做增量。 谁能赢,取决于生态、迁移成本和与元框架的绑定。

六、对后续技术的影响(因果链)

[[Webpack]] 慢 + JS 性能触顶
        │
        ├──► [[Vite]] 用 no-bundle 解决 dev 速度(但超大应用有代价 + 双引擎)
        │
        └──► Webpack 作者 Tobias 亲自用 Rust 重写
                │
                ▼
        Turbopack:Rust 原生性能 + 增量计算(函数级缓存)
                │  ① 目标:增量代价与项目大小无关
                │  ② 内置 Next.js ──► 靠渠道分发
                │  ③ 与 Next.js/Vercel 强绑定 ──► 开放性受限
                │
                ▼
        Rust 打包器三国杀:Turbopack vs [[Vite]]/Rolldown vs Rspack
                │
                ▼
        行业共识固化:打包器 = Rust + 增量 ──► 延续到 Oxc、Biome 等更广的 Rust 工具链

历史地位

Turbopack 的象征意义大于它当前的市场地位:Webpack 的作者亲手用 Rust 重写 Webpack,等于给”JS 工具链时代结束、Rust/Go 工具链时代开始”盖了官方图章。无论 Turbopack 最终能否赢下竞争,它都标记了一个转折点——前端底层基础设施,正在系统性地从 JS 迁往系统级语言。

🔗 相关:前端工程化演进史 | Webpack | Vite | Rollup | Babel | 2018-2023 工程化时代 | 2023-未来 AI时代

关系图谱

反向链接