Rolldown vs esbuild: The Rust Bundler Race 2026

On March 12, 2026, Vite 8.0 shipped with a single headline change: Rolldown replaced the dual esbuild/Rollup bundler with a single Rust-based engine delivering 10-30x faster production builds. This isn't a preview or a beta opt-in. If you used vite build after upgrading to Vite 8, you used Rolldown.

The question developers are now asking: does Rolldown also replace esbuild for use cases outside of Vite? Here's the full comparison.

TL;DR

For Vite projects: Rolldown is already your bundler — it shipped as the default in Vite 8. On large projects (500+ modules), production build times fall 10-30x. For direct esbuild use cases — library bundling, simple build scripts, WASM targets — esbuild still wins on maturity and ecosystem. The real story is that Rolldown unified Vite's dual-bundler architecture and eliminated the dev/prod inconsistency problem that caused hard-to-reproduce bugs for years.

Key Takeaways

Vite 8.0 (March 12, 2026) ships Rolldown as the default production bundler, replacing the Rollup + esbuild dual-architecture
10-30x faster than Rollup on production builds: 19,000-module benchmark completed in 1.61s vs Rollup's 40.10s
Comparable speed to esbuild — Rolldown's WASM build is actually faster than esbuild's (Go's WASM compilation is suboptimal)
Production-scale validation: Mercedes-Benz.io: 38% build time reduction; Beehiiv: 64% reduction
Rollup-compatible plugin API — existing Rollup plugins work with Rolldown without changes
esbuild remains the choice for non-Vite bundling use cases where its Go runtime has a smaller footprint
VoidZero backing: Rolldown is developed under Evan You's VoidZero umbrella, alongside Oxc and Vitest

At a Glance

	Rolldown	esbuild
Language	Rust	Go
Vite integration	✅ Default (Vite 8)	❌ Replaced
Plugin system	Rollup-compatible	esbuild plugins
Tree-shaking	Advanced (Rollup algorithm)	Basic
Code splitting	✅	✅
CSS handling	✅	✅
Module formats	ESM, CJS, IIFE, UMD	ESM, CJS, IIFE
WASM performance	Faster than esbuild WASM	Slower (Go WASM)
Production readiness	Stable (Vite 8)	Stable (years)
Standalone use	✅ `rolldown` npm package	✅ `esbuild` npm package
Config format	JS/TS (Rollup-style)	JS/TS/Go API
GitHub stars	11,000+	38,000+

The Problem Rolldown Solves

Before Rolldown, Vite had a split personality that caused real pain:

Development (vite dev):
  ├── Dependency pre-bundling: esbuild (fast, CJS→ESM transformation)
  └── Module serving: Vite's native ESM server (no bundling)

Production (vite build):
  ├── Application code: Rollup (correct tree-shaking, code splitting)
  └── Dependency pre-bundling: esbuild (same as dev)

The practical consequence: your dev build used esbuild's module resolution, your production build used Rollup's. They produced different output in subtle ways — different handling of CJS dependencies, different code splitting behavior, different treatment of side effects. Bugs that only appeared in production, build artifacts that differed between environments, "works in dev, breaks in prod" issues that took days to debug.

Rolldown replaces both with a single engine:

All environments (vite dev + vite build):
  └── Rolldown (Rust, Rollup-compatible, esbuild-speed)

One bundler, consistent behavior, 10-30x faster than the Rollup half of the old architecture.

Performance Benchmarks

Build Time by Project Scale

Modules	Rolldown	Rollup	esbuild	Speedup vs Rollup
100	0.18s	0.42s	0.09s	2.3x
1,000	0.52s	3.8s	0.31s	7.3x
5,000	0.85s	12.4s	0.68s	14.6x
10,000	1.21s	26.7s	1.02s	22x
19,000	1.61s	40.1s	1.44s	25x

Source: official Rolldown benchmarks, rstackjs/build-tools-performance, 2026

At smaller scales, esbuild still has a slight edge. At large project sizes (the 500+ modules range where the 10-30x claim applies), Rolldown and esbuild are within 10-15% of each other — but Rolldown has Rollup-compatible tree-shaking and the Vite ecosystem integration that esbuild lacks.

Real Production Migrations

Mercedes-Benz.io (beta rolldown-vite):
  Before: ~180s production build
  After:  ~112s production build
  Reduction: 38%

Beehiiv (newsletter platform):
  Before: ~240s production build
  After:  ~86s production build
  Reduction: 64%

The variance in improvement depends heavily on project size and the proportion of work that was previously Rollup's. Smaller Vite projects may see 5-15x improvement; larger ones can see the advertised 10-30x.

Using Rolldown Standalone

Rolldown ships as a standalone npm package, separate from Vite:

npm install rolldown

// rolldown.config.js
import { defineConfig } from "rolldown";

export default defineConfig({
  input: "src/index.ts",
  output: {
    dir: "dist",
    format: "esm",
    sourcemap: true,
  },
  // Rollup plugins work here:
  plugins: [
    // your existing @rollup/* plugins
  ],
});

# Run a build
npx rolldown -c rolldown.config.js

# Or use in package.json
{
  "scripts": {
    "build": "rolldown -c"
  }
}

The Rollup-compatible plugin API means tools like @rollup/plugin-commonjs, @rollup/plugin-node-resolve, and most community plugins work out of the box. If you have an existing Rollup config, migration is usually rename the config file and change the import.

Using esbuild Standalone

esbuild's API is different — more imperative, less convention-driven:

// build.mjs
import * as esbuild from "esbuild";

await esbuild.build({
  entryPoints: ["src/index.ts"],
  bundle: true,
  outdir: "dist",
  format: "esm",
  sourcemap: true,
  splitting: true,
  platform: "node",
  // Tree-shaking via sideEffects
  treeShaking: true,
});

esbuild's Go runtime also offers a programmatic Go API for projects that want to integrate bundling into Go build pipelines — Rolldown has no equivalent.

Tree-Shaking: Where Rolldown Has the Edge

esbuild's tree-shaking is fast but less sophisticated than Rollup's module graph analysis. For library authors shipping tree-shakeable packages, this matters:

// library/src/index.ts
export { formatDate } from "./date";
export { parseCSV } from "./csv";
export { createChart } from "./chart"; // imports heavy D3

// Consumer
import { formatDate } from "my-library";
// Only formatDate should end up in the bundle

esbuild may include more than needed from the re-export chain in complex cases. Rolldown uses Rollup's proven tree-shaking algorithm — the one that the frontend community has relied on for library bundling for years.

# Bundle size comparison for tree-shaking heavy library
esbuild output:  48KB (some unnecessary re-exports included)
Rolldown output: 31KB (clean elimination of unused exports)
Rollup output:   31KB (same algorithm)

The Plugin Ecosystem

This is currently Rolldown's biggest practical limitation vs esbuild's maturity:

esbuild plugins:
  esbuild-plugin-sass       (CSS preprocessing)
  esbuild-plugin-svgr       (SVG as React components)
  esbuild-node-externals     (exclude node_modules)
  @es-joy/esm-lint          (ESM validation)
  esbuild-plugin-alias      (path aliases)
  — hundreds more on npm

Rolldown plugins:
  Works with existing @rollup/* plugins
  Works with Vite plugins (via Vite 8 integration)
  Standalone ecosystem still maturing
  Missing some esbuild-specific plugins with no Rollup equivalent

If your current build relies on a specific esbuild plugin, check for a Rollup equivalent before migrating.

Migration: Rollup Config to Rolldown

# Install
npm install rolldown

# Rename and update
mv rollup.config.js rolldown.config.js

// Before (rollup.config.js)
import { defineConfig } from "rollup";
import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
import typescript from "@rollup/plugin-typescript";

export default defineConfig({
  input: "src/index.ts",
  output: { dir: "dist", format: "esm" },
  plugins: [resolve(), commonjs(), typescript()],
});

// After (rolldown.config.js) — same content, different import
import { defineConfig } from "rolldown";  // ← only this changes
import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
import typescript from "@rollup/plugin-typescript";

export default defineConfig({
  input: "src/index.ts",
  output: { dir: "dist", format: "esm" },
  plugins: [resolve(), commonjs(), typescript()],
});

For most Rollup projects, the migration is a one-line change.

Vite 8 Migration Notes

# Update Vite
npm install vite@8

# No configuration changes needed for basic setups
# Rolldown is the default — vite build now uses it automatically

For complex Vite projects:

// vite.config.ts
import { defineConfig } from "vite";

export default defineConfig({
  // If you need to opt back to Rollup temporarily:
  build: {
    rollupOptions: {
      // Standard Rollup options still work via compat layer
    },
  },
  // Rolldown-specific options:
  experimental: {
    rolldownVersion: "latest",  // Pin if needed
  },
});

When to Use Each

Choose Rolldown when:

You're on Vite 8+ (it's already your bundler — no decision needed)
Migrating from Rollup (plugin compatibility is near-identical)
You need Rollup's advanced tree-shaking and code splitting
Building a large application where build time is a CI bottleneck
You want a single consistent bundler for dev and prod

Choose esbuild when:

Building Node.js libraries or CLIs outside the Vite ecosystem
You need esbuild's Go API for programmatic usage
You have existing esbuild-specific plugins without Rollup equivalents
Targeting WebAssembly as an output format
Simple bundling tasks where esbuild's lower configuration surface is a feature

Compare Rolldown and esbuild download trends at PkgPulse.