Vite vs Turbopack vs Rspack: Which Bundler Should You Use in 2026?

The bundler wars are over — and somehow we ended up with three winners. If you're starting a new React + TypeScript project in 2026, you're almost certainly choosing between Vite, Turbopack, or Rspack. I ran all three against the same real-world monorepo to find out which one actually deserves your package.json. Here's the Vite vs Turbopack vs Rspack breakdown, with numbers.

The Test Setup

I used a monorepo with three packages: a shared UI library (82 components), a marketing site, and a dashboard app. Total: ~140k lines of TypeScript and React, ~950 modules, CSS Modules throughout, a handful of SVG imports, and some hefty third-party deps (Recharts, TanStack Table, date-fns). Nothing exotic — this is what a mid-stage startup's codebase actually looks like.

Hardware: M3 MacBook Pro, 36 GB RAM. Each test run three times, median taken. Versions: Vite 6.2, Turbopack (Next.js 15.3), Rspack 1.3.

One note before the numbers: Turbopack is still tightly coupled to Next.js. You can't just swap it into a Remix or plain React project. That matters, and I'll come back to it.

Cold Start: Dev Server Boot Time

This is the metric you feel every single morning.

Rspack wins cold start convincingly. It's doing what it promised: Rust-speed Webpack semantics. Vite is close behind and still feels instant in practice. Turbopack is the slowest here, which surprised me — but it's doing more work upfront (RSC compilation, route analysis). If you're using Next.js App Router, that overhead buys you something. If you're not, it's just overhead.

HMR: The Metric That Actually Affects Your Day

I edited a leaf component (button style change), a mid-tree component (dashboard layout), and a root provider. Times measured from save to browser paint.

Turbopack's HMR is in a different league. The incremental computation engine Vercel has been building since 2022 finally pays off here — edits to deeply imported modules barely register. Vite's HMR is still excellent for leaf edits, but cascading invalidation hits harder as you go up the tree. Rspack behaves like Webpack always did: fine for small edits, noticeably sluggish for broad changes.

For a team of five devs making hundreds of saves a day, Turbopack's HMR advantage is real. It's the kind of thing you don't notice until you switch back.

Production Build: Size and Speed

Vite 6's switch to Rolldown for production builds closed the dev/prod gap that plagued earlier versions. Build output is the smallest here thanks to Rolldown's tree-shaking, which is noticeably better than Rspack's. Rspack builds fastest, but the 13 KB difference in bundle size adds up across routes in a large app.

Turbopack's production build is fine. Not remarkable. The output is slightly larger because Next.js injects its own runtime, and there's less control over chunking strategy than the other two give you.

Plugin Ecosystem and Config Reality

This is where the vibes diverge sharply from the benchmarks.

Vite has the richest plugin ecosystem by a wide margin. Need to import MDX, GraphQL files, SVGs as components, WASM modules? There's a mature, maintained plugin. The Rollup-compatible plugin API means years of community work carries forward. When something breaks, you'll find a GitHub issue or Stack Overflow thread about it.

Rspack is Webpack-compatible, which sounds great until you find out it's mostly Webpack-compatible. About 80% of Webpack loaders work out of the box. The other 20% fail silently or throw cryptic Rust-side panics. I spent 20 minutes debugging why svg-react-loader wasn't working before finding a two-week-old GitHub issue confirming it's not yet supported. The docs don't mention this. If your project uses mainstream loaders, you're fine. If you've got anything unusual, budget time for migration surprises.

Turbopack has the smallest plugin surface. Vercel's position is that Next.js conventions replace most plugin needs. That's true if you're all-in on Next.js. It's a non-starter if you're not.

Here's what a basic Vite config looks like for our monorepo — straightforward and readable:

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react-swc';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig({
  plugins: [react(), tsconfigPaths()],
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ['react', 'react-dom'],
          charts: ['recharts'],
        },
      },
    },
  },
});

And the Rspack equivalent — familiar if you've written Webpack configs, but more verbose:

// rspack.config.ts
import { defineConfig } from '@rspack/cli';

export default defineConfig({
  resolve: {
    tsconfigPaths: true,
    extensions: ['.ts', '.tsx', '.js'],
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: { loader: 'builtin:swc-loader',
          options: { jsc: { parser: { syntax: 'typescript', tsx: true } } }
        },
      },
    ],
  },
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: { test: /[\\/]node_modules[\\/](react|react-dom)/, name: 'vendor', chunks: 'all' },
      },
    },
  },
});

If you're migrating from Webpack, Rspack's config familiarity is a genuine advantage. If you're starting fresh, Vite's config is just nicer.

Monitoring What You Ship

Whichever bundler you pick, keep an eye on what it outputs. DebugBear is solid for tracking bundle size regressions and Core Web Vitals over time — useful when you're evaluating whether a bundler switch actually improved things in production, not just in your terminal. Sentry integrates with all three bundlers for source map uploads if you need error tracking with readable stack traces.

The Framework Lock-in Problem

This is the elephant. Turbopack requires Next.js. Full stop. You can't use it with Remix, Astro, or a plain Vite-style dev server. If you're already on Next.js and happy, this is irrelevant. If you value the ability to switch frameworks without replacing your entire build toolchain, it's disqualifying.

Rspack and Vite are both framework-agnostic. Rspack works anywhere Webpack does. Vite works with React, Vue, Svelte, Solid, Astro — basically everything.

The Verdict

Use Vite if you want the best all-round experience. The plugin ecosystem is unmatched, Rolldown has eliminated the production build weakness, and the DX is exceptional. It's the safe, excellent default. For most teams, this is the answer.

Use Turbopack if you're committed to Next.js and HMR speed on a large codebase is your top priority. The incremental engine is genuinely impressive, and it'll only get better. But you're buying into the Vercel ecosystem — go in with eyes open. If you're deploying to Vercel, the integration is seamless and the deployment pipeline is optimised for this exact stack.

Use Rspack if you're migrating a large Webpack project and can't afford a full config rewrite. The Webpack compatibility saves weeks of migration work. But don't choose it for a greenfield project — Vite's DX is better, and the ecosystem is deeper.

My monorepo is staying on Vite. The cold start is fast enough, the HMR is fast enough, and when something goes wrong, I can actually debug it without reading Rust panic traces. That last part matters more than any benchmark.