Last month I migrated a production React app across three different build tools in a single week. 800 components. 140 route pages. A dozen third-party libraries. Not because I was bored. Because my team's webpack build had crossed the 30-second cold start threshold and developers were literally alt-tabbing to Twitter while waiting. That week taught me more about the real state of Vite vs Turbopack vs Rspack than any blog post I'd read.
In 2026, the frontend build tool race has narrowed to three serious contenders, all running on Rust (or Rust-adjacent) toolchains. But the marketing claims are wildly inconsistent, and honest benchmarks on non-trivial projects are surprisingly hard to find. So I ran my own.
The Test Setup: No Toy Apps Allowed
Most build tool benchmarks use starter templates with five components. That tells you nothing about real-world performance. Here's what I tested against:
- App size: 800 React components, 140 routes, ~95,000 lines of TypeScript
- Dependencies: React 19, React Router, Zustand, Tanstack Query, three design system libraries, plus a charting package
- Machine: M3 MacBook Pro, 18GB RAM, macOS Sequoia
- Metrics: Cold dev start (time to first browser load), HMR speed (time from file save to browser update on a deeply nested component), and production build time (full optimized output)
- Runs: Each metric measured 5 times, median taken
I tested Rspack 1.x, Turbopack via Next.js 15 (the only way to use it), and Vite 8 with Rolldown, the new Rust-based bundler that replaced esbuild under the hood.
One caveat worth flagging: Turbopack required restructuring the app to run inside Next.js, since it's not available as a standalone bundler. I kept the component tree identical but had to adapt routing. That fact alone tells you something.
Vite vs Turbopack vs Rspack: The Benchmark Results
Here's what the numbers looked like:
| Metric | Rspack 1.x | Turbopack (Next.js 15) | Vite 8 (Rolldown) |
|---|---|---|---|
| Cold dev start | 1.4s | 2.1s | 2.8s |
| HMR (deep component) | 160ms | 70ms | 130ms |
| Production build | 3.4s | N/A (Next.js build: 8.2s) | 4.1s |
| Webpack config reuse | ~95% compatible | 0% (new config) | 0% (new config) |
These numbers roughly align with Rspack's own published benchmarks. They claim 1.36s dev start, 160ms HMR, and 3.35s build on their reference project. My slightly larger app tracked close.
Let me break down what actually matters here.
Rspack wins cold starts decisively. 1.4 seconds from zero to browser-ready. Noticeably faster than both competitors. This matters more than people think. Cold starts happen every time you switch branches, reboot, or pull a teammate's changes. Over a full day of development, those seconds compound into minutes. I've been on teams where slow tooling silently destroyed flow state for weeks before anyone even named the problem. Cold start speed is the single most underrated build metric.
Turbopack's HMR is absurdly fast. 70 milliseconds. On a deeply nested component four levels down in the tree. Not a typo. Tobias Koppers, the creator of webpack who now leads Turbopack at Vercel, built an incremental architecture that caches aggressively and never recomputes work it's already done. If your workflow involves tweaking UI components dozens of times per hour, nothing else comes close.
Vite 8 is the most balanced option. Not the fastest at any single metric, but competitive across all of them. The Rolldown integration is a real leap forward. Evan You and the Vite team replaced the previous esbuild/Rollup split with a single Rust-powered bundler that handles both dev and production. Faster builds, better consistency between dev and prod behavior, and a much simpler internal architecture.
If you've been tracking the JavaScript bloat problem in frontend, you'll appreciate that all three tools now handle tree-shaking and code splitting at near-native speed.
The Turbopack Lock-In Problem Nobody Talks About
Here's the thing nobody's saying about Turbopack: it's brilliant technology trapped inside a single framework.
As of mid-2026, Turbopack is only usable through Next.js. No standalone CLI. No Vite-like adapter for Remix, SvelteKit, Nuxt, or vanilla React. Vercel has talked about making it framework-agnostic eventually, but "eventually" has been the answer for over three years now. I'm tired of waiting.
This means choosing Turbopack is really choosing Next.js. For some teams, that's fine. Next.js is excellent. But for teams using Remix, Astro, or any non-Next React setup, Turbopack simply isn't an option. That's a massive ecosystem constraint that gets buried under the performance headlines.
I've shipped enough features across different frameworks to know that coupling your build tool to your framework is a risk. Frameworks fall in and out of favor. Build tools shouldn't force your hand on that decision.
The production build comparison is also awkward. Turbopack handles the dev server; Next.js's production build is a separate pipeline. My "8.2 seconds" number includes Next.js's own compilation steps, server component processing, and static generation. It's not apples-to-apples with Rspack and Vite's pure client-side builds, so I flagged it as N/A for the raw Turbopack column.
If Turbopack ever ships as a standalone tool, it becomes the most interesting option overnight. Until then, it's the best build tool you might not be able to use.
Why Rspack Is Winning the Migration War
Rspack's secret weapon isn't raw speed. It's compatibility.
Built by ByteDance's web infrastructure team, Rspack was designed from day one as a drop-in webpack replacement. Your existing webpack.config.js? It probably works. Your loaders? Most of them work. Your plugins? The popular ones are supported or have Rspack equivalents.
In my migration test, I got the 800-component app running on Rspack in about four hours. Most of that was tracking down two webpack plugins that needed alternatives. With Vite, the migration took closer to two full days because the config model is fundamentally different. Vite uses Rollup-style plugins, different dev server assumptions, and a different approach to module resolution. It's not bad. It's just different enough to cost you real time.
For large teams sitting on mature webpack codebases, this is the deciding factor. I've seen migration projects estimated at two sprints balloon to six because of build tool config differences. Rspack eliminates most of that pain.
This matters especially if you're dealing with the kind of performance engineering decisions where build tooling directly impacts your CI/CD pipeline and deployment velocity.
Which Build Tool Should You Actually Pick?
After a week of benchmarking and a lot of node_modules folders, here's my honest take:
Pick Rspack if you're migrating from webpack and want the fastest path to a Rust-powered build with minimal config changes. It's the pragmatic choice. Your team keeps their existing mental model, builds get 10-15x faster, and nobody has to relearn anything. This is one of those things where the boring answer is actually the right one.
Pick Turbopack if you're already all-in on Next.js and HMR speed is your top priority. For Next.js shops doing heavy component development, Turbopack's 70ms hot reloads change the way you work. Just understand you're betting on Vercel's roadmap.
Pick Vite 8 if you want maximum flexibility. Vite works with React, Vue, Svelte, Solid, Astro, Remix, and basically everything else. The Rolldown upgrade has closed the performance gap significantly, and its plugin ecosystem is the most mature of the three. For new projects where you're not locked into a framework, Vite is the safest high-performance choice.
For what it's worth, if I were starting a greenfield React project today that didn't need Next.js-specific features like server components, I'd pick Vite 8. The combination of performance, ecosystem breadth, and framework flexibility is hard to argue with.
The Rust Build Tool Era Is Here. The Winner Isn't Decided Yet.
Here's what I keep coming back to: all three tools are remarkably good. We went from 30-second webpack cold starts to sub-3-second dev servers across the board. The cold start performance gains we've seen in serverless are now happening in local development tooling, driven by the same Rust-powered architecture trend.
The real competition isn't about milliseconds anymore. It's about ecosystem gravity. Turbopack has Vercel and Next.js behind it. Rspack has ByteDance and the entire webpack ecosystem. Vite has Evan You, the broadest framework support, and now Rolldown closing the raw speed gap.
My prediction: by the end of 2026, Vite and Rspack will converge on performance, and the choice will come down to whether you're migrating an existing webpack codebase (Rspack) or building something new (Vite). Turbopack will remain the best option inside Next.js but won't break out of that silo.
The webpack era lasted over a decade. The Rust build tool era is just getting started. And for the first time in years, waiting for your build isn't the bottleneck. Your architecture decisions are.
Originally published on kunalganglani.com
Top comments (0)