The vite vs turbopack debate has quietly settled into two distinct camps — and if you're starting a React project in 2026, picking the wrong one costs you more than just HMR speed. Turbopack is now the default bundler in Next.js 15, shipping with every create-next-app scaffold. Vite, meanwhile, has cemented its position as the go-to for everything else: Remix, React Router v7, Astro, Tanstack Start, and bare React SPAs alike.
These aren't interchangeable tools with different performance profiles. They serve different ecosystems and make different trade-offs. Here's how to pick one without regret.
What Turbopack Actually Gets Right
The "10x faster HMR" claim comes from Vercel's own benchmarks on large Next.js apps. That number is real — but it's real in a specific context: apps with hundreds of routes, heavy RSC usage, and the kind of module graph that made Webpack grind your fan to submission. On a 20-component project, you won't notice a difference.
What Turbopack genuinely nails is lazy compilation. Rather than compiling the entire module graph on cold start, it only compiles modules actually requested by the browser. On a large Next.js codebase, this makes the dev server feel instant even when your app has 300+ routes.
The integration with Next.js 15 is seamless in a way that would take custom Vite plugins to replicate. Turbopack understands App Router, Server Components, and route groups natively. Enabling it is one flag:
// next.config.ts
const nextConfig = {
experimental: {
turbo: {
rules: {
'*.svg': {
loaders: ['@svgr/webpack'],
as: '*.js',
},
},
},
},
};
export default nextConfig;Or just run next dev --turbo. No separate config file, no plugin wrangling. The docs don't make this obvious, but that's all there is to it.
The catch: Turbopack is still dev-only. Production builds in Next.js 15 still use Webpack. Vercel has been transparent about this — Turbopack production builds are coming, but they're not stable yet. So when someone says "Turbopack speeds up our builds", they mean dev server restarts, not CI pipeline times. Keep that distinction in mind when reading the benchmark posts.
Where Vite Still Wins in 2026
Vite's advantage has never been raw speed — it's the ecosystem. There are over 900 Vite plugins on npm right now. Need PWA support? vite-plugin-pwa. SVG imports as React components? vite-plugin-svgr. Bundle visualiser? rollup-plugin-visualizer. Most things you'd want to do to a frontend build pipeline have a Vite plugin that just works, maintained by someone who actually uses it.
The config API is also genuinely ergonomic. A real Vite config for a React + TypeScript project with path aliases and an API proxy:
// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { resolve } from 'path';
export default defineConfig({
plugins: [react()],
resolve: {
alias: {
'@': resolve(__dirname, './src'),
},
},
server: {
proxy: {
'/api': {
target: 'http://localhost:3001',
changeOrigin: true,
},
},
},
build: {
rollupOptions: {
output: {
manualChunks: {
vendor: ['react', 'react-dom'],
},
},
},
},
});Forty lines. No inheritance chain, no implicit convention magic, no wondering what the framework is doing behind the scenes. This is why Vite became the default for non-opinionated setups — the config is just JavaScript, readable by any developer who joined the project six months ago.
Vite also produces actual production builds. Run vite build and you get a Rollup-optimised bundle you can deploy anywhere — Netlify, DigitalOcean App Platform, a CDN, a static file server. No framework lock-in baked into the output.
The one area where Vite historically struggled is very large projects — apps with 2000+ modules where esbuild's lack of persistent caching caused slow cold starts. Vite 6 improved this with better dependency pre-bundling, but if you're at that scale and already on Next.js, Turbopack will feel noticeably snappier in dev. That's a real trade-off, not benchmark noise.
The Framework Lock-In Question
This is the real decision point, and it's one the benchmarks don't capture.
Turbopack is a Vercel project. It's open source, but the roadmap is driven by Next.js needs. If you're building a Next.js app and deploying to Vercel, Turbopack's trajectory is perfectly aligned with yours — Vercel has every incentive to make it fast and stable for that exact use case. The alignment is genuine and the investment is substantial.
But if you're on Remix, React Router v7, Astro, or a plain React SPA — Turbopack is not an option. It's not designed to be. Vite is the default for every one of those frameworks, and that's not changing. The broader RSC conversation (which we covered in React Server Component patterns that replaced client-side data fetching) is moving faster on Vite-backed frameworks than people realise.
Team size matters here too. Turbopack requires zero configuration — which is a feature if your team is two developers shipping a Next.js app. It's a constraint if you have custom build requirements, a monorepo with shared packages, or non-standard asset pipelines. Vite's escape hatches are well-documented and battle-tested. Turbopack's are still being built. I spent 20 minutes last month trying to get a custom Turbopack loader working in a monorepo before giving up and reaching for a Vite config instead. The docs don't mention half of what you need.
Quick Decision Matrix
- Next.js 15 app, large codebase (>100 routes): Turbopack. The lazy compilation alone makes it worth it.
- Next.js 15 app, small-to-medium size: Either. Turbopack is the default — don't fight it, but you won't feel a speed difference.
- Remix / React Router v7 / Astro: Vite. There is no choice here.
- Plain React SPA, no framework: Vite. Every scaffold, every tutorial, every plugin targets Vite.
- Monorepo with custom asset pipeline: Vite. The config flexibility is not optional at that scale.
- Proof of concept or internal tool: Vite. Fastest to get running, easiest to hand off.
If you want to see how Vite and Turbopack compare against Rspack and Farm on identical benchmark apps, the four-bundler comparison has cold start and HMR numbers side by side.
The Verdict
Use Turbopack if you're on Next.js 15 and your dev server is noticeably slow on a large codebase. The setup cost is zero and the DX improvement on big apps is real. Accept that production builds still go through Webpack for now — that will change, but it hasn't yet.
Use Vite for everything else. It's mature, fast enough for 95% of projects, has the widest framework support of any bundler in 2026, and the plugin ecosystem means you're rarely writing custom build logic from scratch. Vite is also the right call if you need production build portability — your output doesn't care where it gets deployed.
The one thing to avoid: choosing Turbopack for a non-Next.js project because of the benchmark headlines. Those numbers come from Next.js apps with hundreds of RSC modules. They don't transfer to a Vite project, and Turbopack won't even run outside Next.js without significant undocumented effort. Save yourself the rabbit hole.