Skip to content

Turbopack and Next-Gen Bundlers

intermediate16 min read

The Rust Wave in Build Tooling

Something interesting is happening in the JavaScript ecosystem: the tools we use to build JavaScript apps are being rewritten in Rust. Not incrementally improved — fully rewritten from scratch.

Turbopack, Rspack, Farm, Mako, Rolldown — these are all Rust-based bundlers that launched between 2022 and 2024. This isn't a coincidence. There's a convergence of factors making Rust the language of choice for the next generation of build tools.

Mental Model

Think of this shift like the transition from horse carriages to automobiles. The old tools (webpack in JavaScript) are like highly refined carriages — decades of optimization, every edge case handled, massive ecosystems of accessories. The new tools (Turbopack, Rspack in Rust) are early automobiles — faster by nature (native code), but still catching up in features and polish. The question isn't whether the transition happens, it's how long the overlap period lasts and which new vehicle dominates.

Why Rust Is Winning

Every next-gen bundler chose Rust. Here's why:

Memory Safety Without GC

Rust's ownership system eliminates entire categories of bugs (use-after-free, data races, null pointer dereferences) at compile time, without a garbage collector. This means:

  • No GC pauses during builds
  • Predictable, consistent performance
  • Safe parallelism guaranteed by the compiler

Zero-Cost Abstractions

Rust's abstractions compile away completely. You write high-level code (iterators, pattern matching, traits) that compiles to the same machine code you'd write by hand in C. There's no runtime overhead for abstraction.

Fearless Concurrency

Rust's type system prevents data races at compile time. You can confidently parallelize build operations knowing the compiler will catch concurrency bugs before they become runtime crashes.

WASM Compilation Target

Rust compiles to WebAssembly efficiently. This matters because build tool plugins can be distributed as WASM modules, running at near-native speed in any environment.

Quiz
Why did most next-gen bundlers choose Rust over Go (which esbuild uses)?

Turbopack: Incremental Computation

Turbopack, created by Vercel (the Next.js team), is the most architecturally ambitious of the next-gen bundlers. Its core innovation isn't just "Rust is fast" — it's incremental computation.

The Turbo Engine

Under Turbopack is the Turbo engine — a Rust-based incremental computation framework. Here's the key idea:

Traditional bundlers recompute from scratch (or from a coarse cache) when a file changes. Even webpack's HMR rebuilds the entire subgraph of a changed module.

Turbopack tracks every function call and its inputs during a build. When a file changes, it only re-executes the specific functions whose inputs changed. Everything else reuses cached results.

Traditional bundler (file changes):
  Recompile changed file
  → Re-resolve its imports
  → Re-link affected chunk
  → Re-optimize affected chunk
  → Re-emit affected output files
  [===== 500ms-5s =====]

Turbopack (file changes):
  Recompile changed file (only the changed parts)
  → Check: did the exports change? No → stop here
  → Check: did the exports change? Yes → re-link only affected consumers
  → Re-emit only the changed bytes
  [= 10-50ms =]
Execution Trace
Initial build
Turbo engine executes all build functions, recording inputs and outputs
Every function call is memoized with its dependencies
File saved
src/Button.tsx content changes
Turbo engine detects this input changed
Invalidation
Find all functions that depend on Button.tsx's content
Only the parse and transform functions for this file
Re-execution
Re-run only invalidated functions
If the exports didn't change, dependents aren't invalidated
Cascading check
Did the output of re-executed functions change?
No change in exports = no further invalidation. Change = invalidate dependents
Minimal update
Only changed output bytes are sent to the browser
Most of the build graph remains cached and untouched

Turbopack in Next.js

Turbopack is integrated into Next.js as the development bundler. As of Next.js 15, you enable it with:

next dev --turbopack

What Turbopack handles in Next.js:

  • Development compilation (replacing webpack for dev)
  • HMR (faster than webpack-based HMR)
  • React Server Components compilation
  • CSS Modules and PostCSS processing
  • TypeScript and JSX transformation (via SWC)

Turbopack is stable for development in Next.js 15. Production builds still use webpack (Turbopack production support is in progress).

Quiz
What makes Turbopack's incremental computation different from webpack's caching?

Rspack: Webpack-Compatible, Rust-Fast

Rspack (created by ByteDance) takes a completely different approach than Turbopack. Instead of reimagining bundler architecture, Rspack aims to be a faster webpack — compatible with webpack's configuration API and plugin system.

// rspack.config.js — looks exactly like webpack config
const { HtmlRspackPlugin } = require('@rspack/core');

module.exports = {
  entry: './src/index.js',
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: {
          loader: 'builtin:swc-loader',
          options: {
            jsc: { parser: { syntax: 'typescript', tsx: true } },
          },
        },
      },
    ],
  },
  plugins: [new HtmlRspackPlugin({ template: './index.html' })],
  optimization: {
    splitChunks: { chunks: 'all' },
  },
};

Rspack's Migration Story

This is Rspack's killer feature: you can migrate from webpack to Rspack with minimal config changes. Many webpack loaders and plugins work directly. Where they don't, Rspack provides built-in alternatives:

  • builtin:swc-loader replaces babel-loader/ts-loader
  • HtmlRspackPlugin replaces HtmlWebpackPlugin
  • CssExtractRspackPlugin replaces MiniCssExtractPlugin

For large teams with massive webpack configs, Rspack offers a pragmatic upgrade path: keep your config, get 5-10x faster builds.

AspectTurbopackRspack
CreatorVercelByteDance
PhilosophyClean-slate architecture with incremental computationWebpack-compatible, faster implementation
Webpack config compatibilityNo — different config formatHigh — most webpack configs work with minor changes
Webpack plugin compatibilityNo — different plugin APIPartial — many plugins work, some need alternatives
Production buildsIn progressYes — stable for production
Framework integrationNext.js (dev only)Standalone, Rsbuild framework
MaturityStable for dev in Next.js 15Production-ready, used at ByteDance scale

Other Next-Gen Bundlers

Rolldown

Rolldown is particularly interesting: it's a Rust port of Rollup, built by the Vite team. The goal is to eventually replace both esbuild (dev pre-bundling) and Rollup (production builds) in Vite with a single tool.

Why this matters: Vite currently uses different bundlers for dev and production, which occasionally causes behavior differences. Rolldown would unify them — same bundler, same behavior, native speed everywhere.

Farm

Farm is a Rust-based build tool with a focus on extremely fast HMR. It supports both development and production, uses SWC under the hood, and has first-class support for partial bundling — a strategy between "bundle everything" and "bundle nothing" that aims for optimal chunk granularity.

Quiz
A large team has a complex webpack config with 50+ plugins and custom loaders. They want faster builds. Which migration path requires the least effort?

Migration Strategies

From Webpack to Vite

Best for: greenfield projects, smaller apps, React/Vue/Svelte projects

  1. Install Vite and the framework plugin
  2. Move entry HTML to project root
  3. Replace webpack-specific imports (file-loader URLs, etc.) with Vite equivalents
  4. Replace webpack dev server middleware with Vite plugin hooks
  5. Update environment variable usage (process.env to import.meta.env)

From Webpack to Rspack

Best for: large teams with complex webpack configs, incremental migration

  1. Install @rspack/core and @rspack/cli
  2. Rename webpack.config.js to rspack.config.js
  3. Replace webpack imports with @rspack/core imports
  4. Swap incompatible plugins with Rspack built-in equivalents
  5. Replace babel-loader with builtin:swc-loader

From Webpack to Turbopack (Next.js only)

Best for: Next.js projects wanting faster dev experience

  1. Update to Next.js 15+
  2. Run next dev --turbopack
  3. Address any unsupported webpack config in next.config.js
Common Trap

Don't assume "Rust-based = always better." Turbopack is still dev-only for production builds. Rspack's webpack plugin compatibility isn't 100%. Rolldown is still in development. For production-critical builds, verify that your specific use case is supported before migrating. The ecosystem is moving fast, but stability matters more than speed for production.

What developers doWhat they should do
Migrating to a next-gen bundler without checking plugin compatibility first
A single incompatible plugin (like a custom webpack plugin using obscure compiler hooks) can block the entire migration. Check first, then decide.
Audit your webpack plugins/loaders against the target bundler's compatibility list before committing to migration
Using Turbopack for production builds
Turbopack's production build support is still in progress. Using it for production before it's stable risks build failures or incorrect output.
Turbopack is stable for development in Next.js 15. Production builds still use webpack (or use Rspack if you need Rust-speed production builds)
Rewriting a working webpack config from scratch for marginal gains
Sometimes replacing babel-loader with swc-loader in your existing webpack config gives you 80% of the speed gain with 5% of the migration effort.
Profile your build first — the bottleneck might be a specific loader or plugin, fixable without a full migration
Key Rules
  1. 1Rust is winning the build tooling race because of memory safety without GC, zero-cost abstractions, and compile-time concurrency guarantees.
  2. 2Turbopack's key innovation is function-level incremental computation — it re-executes only the specific functions whose inputs changed, not entire modules.
  3. 3Rspack is the pragmatic choice for webpack-heavy projects — it's webpack-compatible config with 5-10x faster builds.
  4. 4Rolldown (Rust Rollup) aims to unify Vite's dev and production bundlers into a single tool.
  5. 5Always verify plugin/loader compatibility before migrating to a next-gen bundler. The ecosystem is still maturing.
  6. 6For Next.js: use Turbopack for dev (--turbopack flag), webpack for production. This gives you the best of both worlds today.