Comparison
Vite or Turbopack? Your framework already chose
The verdict
If you are building on Next.js, use Turbopack. It has been stable for both development and production builds and the default bundler since Next.js 16, it is what the framework team tests against, and fighting it to keep webpack is a maintenance tax with no upside. For literally everything else - Vue, Svelte, Solid, Astro, React Router, a plain TypeScript app, a component library - use Vite 8. Since March 2026 it runs on Rolldown as a single Rust bundler for dev and production, which closed the last real gap in its story. Treating this as an open comparison is the mistake: for the vast majority of projects, picking the framework picks the bundler, and both defaults happen to be good.
The honest framing matters here because the two tools are not substitutes. Turbopack is the bundler inside Next.js and there is no meaningful way to adopt it standalone for an arbitrary project. Vite is a general-purpose build tool that dozens of frameworks are built on. So the real question is rarely "which bundler is faster" and almost always "am I on Next.js or not".
Vite 8 vs Turbopack on the dimensions that decide it
The speed figures below are the ones each project publishes about itself. Treat them as claims, not measurements: both are comparisons against their own previous versions, not head-to-head against each other, and neither ports cleanly to your repository.
| Dimension | Vite 8 | Turbopack |
|---|---|---|
| Where you can use it | Anywhere. Nuxt, SvelteKit, Astro, React Router, Qwik, Storybook, and Vitest all build on it, and it works standalone. | Inside Next.js. That is not a criticism, it is the design: it is Vercel's bundler for Vercel's framework. |
| Architecture | Rolldown as one Rust bundler for dev and production, with Oxc for transforms. Ends the old esbuild-in-dev, Rollup-in-prod mismatch. | Rust, incremental by design, with a function-level dependency graph that recomputes only what changed. |
| Published speed claims | Up to 10-30x faster builds than the previous Rollup path. Named migrations include one going from 46 seconds to 6. | 2-5x faster production builds and up to 10x faster Fast Refresh versus the webpack path it replaced. |
| Dev and prod parity | One bundler now handles both, which removes a long-standing class of "works in dev, breaks in the build" bugs. | Same engine for both since it went stable, with an optional filesystem cache that survives restarts. |
| Plugin ecosystem | Large and portable, built on the Rollup plugin interface, with a dedicated plugin registry. The strongest single argument for Vite. | Deliberately narrow. Partial webpack loader compatibility, and you mostly configure rather than extend. |
| Configuration burden | A config file you own. Sensible defaults, but a big app accumulates plugins and aliases you maintain. | Nearly none. The framework owns it. Wonderful until you need something the framework does not expose. |
| Governance | Independent open source with wide corporate participation and a large contributor base. | Built and staffed by Vercel, shipped as part of Next.js. |
| Exit cost | Low. Standard ES modules plus a config file; moving to another bundler is a day, not a quarter. | Effectively the cost of leaving Next.js, since the bundler is not the part you would migrate on its own. |
When each one is the right call
Choose Vite when
- You are not on Next.js. This covers most of the field and settles the question immediately.
- You publish a library or a design system and need precise control over output formats, externals, and tree shaking.
- Your build depends on plugins - SVG components, WebAssembly, custom file types, legacy browser output - and you want them to keep working.
- You run Vitest, because sharing one transform pipeline between tests and the app removes a whole category of configuration drift.
- You want the bundler decoupled from the framework, so a framework change does not become a build rewrite.
- You are migrating off webpack on a non-Next codebase and want the largest pool of existing migration guides.
Choose Turbopack when
- You are on Next.js 16 or later, where it is the tested default and opting out is the unusual path.
- Your Next.js app is large and dev-server cold starts and Fast Refresh latency are the daily pain, which is exactly what it targets.
- You want zero bundler configuration and are happy for the framework to own that surface entirely.
- You use React Server Components and the App Router, where the bundler and the framework's rendering model are tightly coupled by design.
- Your team's time is better spent on product than on maintaining a custom webpack config that nobody fully understands.
What actually changed, and what to do about it
Vite's Rolldown migration is the more structurally interesting of the two changes. For years Vite used esbuild for dependency pre-bundling in development and Rollup for production builds, and that split produced a real, recurring class of bug: code that worked in the dev server and failed in the build because two different tools disagreed about a module. Vite 8 collapses both onto Rolldown. The speed headline is nice; the parity is what actually reduces your defect count.
Turbopack's story is one of finally shipping. It was announced years before it became the default, spent a long time in beta, and reached stability for both dev and production in Next.js 16. Adoption data published at the time showed it was already carrying more than half of Next.js development sessions before it became the default. The migration path is deliberately dull: for most apps you do nothing, and if you have a custom webpack setup you keep it by passing a flag until you can retire it.
The comparison people actually want - a head-to-head benchmark - is not very useful, because you cannot run a real Next.js app on Vite or a real SvelteKit app on Turbopack. Every published number pits each tool against its own predecessor. Both are Rust, both are incremental, and both are enormously faster than the JavaScript-based tooling of five years ago. On a mid-sized application either will give you a dev server that starts in a second or two and a production build measured in seconds rather than minutes.
Where you should spend attention instead is caching and CI. A bundler that is 5x faster locally saves you nothing if your pipeline reinstalls node_modules and discards the build cache on every run. Turbopack's filesystem cache and Vite's dependency pre-bundling cache both want to be preserved between runs, and wiring that into your CI cache keys will usually beat any bundler swap you are considering.
One genuine risk worth naming on each side. For Turbopack, the risk is coupling: your build tool is a component of one company's framework, so its roadmap is that framework's roadmap. For Vite, the risk is churn: Rolldown is young relative to Rollup, and a plugin that reaches into bundler internals rather than sticking to the documented interface may need work. Neither risk is large enough to change the recommendation. Official sites: vite.dev and nextjs.org.
Where this fits in a build pipeline
The wider field - esbuild, Rspack, tsdown, and what the Rust bundler wave means for your config - is covered in the JavaScript build tools roundup. If the framework question is still open, the Next.js vs Astro comparison is the decision that determines this one.
Build caching across a monorepo is a different problem: see Turborepo compared with Nx. For running these builds on every push, the CI/CD pipeline guide covers cache keys and artefact handling, and the frontend tool directory maps the rest of the layer.