Three build tools are fighting for the same job right now, and the fight got a lot more interesting this month. Rolldown, the Rust bundler that now powers Vite 8, hit its full 1.0 milestone in May 2026 and kept shipping fast, with version 1.2.11 landing on npm this week. Rspack, ByteDance’s webpack-compatible bundler, sits at core version 2.2.8. Turbopack, Vercel’s bundler, has been the default in Next.js since version 16.0.0 and now ships inside Next.js 16.3.6. None of these are side projects anymore. Each has a company behind it, a release cadence measured in days rather than months, and a specific answer to the question that has haunted JavaScript tooling for a decade: why does rebuilding a large app still feel slow.
This comparison pulls live data as of September 28, 2026, straight from the npm registry and GitHub’s API, plus benchmark claims from the vendors and independent reviewers. It covers Vite 8 (now running on Rolldown instead of Rollup), Rspack (ByteDance’s webpack drop-in), and Turbopack (Vercel’s Next.js-native bundler). If you’re picking a build tool for a new project, or wondering whether to migrate off webpack, the numbers below should settle most of the argument. For a broader look at where build tooling fits into the rest of the modern developer stack, see our coding tools guide.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Vite 8, Rspack, and Turbopack Are Colliding in 2026
For most of the 2020s, the build-tool conversation was simple: webpack for anything serious, Vite for anything that valued developer experience, and esbuild or Rollup doing the grunt work underneath. That settled arrangement broke down once Rust-based tooling proved it could outrun JavaScript-based bundlers by a wide margin. Three separate teams, backed by three separate companies, decided to build their own answer instead of waiting for someone else to fix webpack.
VoidZero, the tooling company founded around the Vite ecosystem, rebuilt Vite’s production bundler from the ground up and named it Rolldown. ByteDance’s web infrastructure team built Rspack to let large webpack codebases migrate without rewriting every loader and plugin. Vercel built Turbopack specifically for Next.js, betting that framework-specific optimization would beat a general-purpose bundler for its own use case. All three are written in Rust. All three claim dramatic speed gains. Only one of them is actually free of a specific framework, and that distinction matters more than any single benchmark number.
The underlying driver is simple physics. JavaScript, running single-threaded on V8, was never going to match a compiled language for parsing and transforming millions of lines of source code across a large monorepo. Every team building these tools reached the same conclusion independently: move the CPU-heavy work (parsing, AST transforms, tree-shaking, minification) into Rust, and keep the JavaScript layer for configuration and plugin orchestration. That’s why Vite, Rspack, and Turbopack all look structurally similar under the hood even though they were built by three unrelated organizations with three different priorities.
What makes this particular moment worth writing about is timing. Rolldown’s 1.0 release in May 2026 removed the last real objection to using it in production. Rspack’s core package has been iterating fast enough to reach version 2.2.8 by late September. And Turbopack, after years of being labeled “experimental” in Next.js release notes, is now simply the default, no flag required. All three crossed from promising side project to production-grade infrastructure within roughly the same twelve-month window, which is exactly why so many teams are re-evaluating their build tooling right now instead of waiting another year.
What Changed: Vite 8 Swaps Rollup for Rolldown
Vite has always used two engines under the hood: esbuild for fast dependency pre-bundling during development, and Rollup for the final production build. Vite 8 changes half of that equation. Production bundling now runs through Rolldown, a Rust rewrite that VoidZero designed to stay close to Rollup’s plugin API while dropping the JavaScript performance ceiling that Rollup was built on.
VoidZero’s own announcement, posted when Rolldown hit 1.0 stable on May 7, 2026, describes builds running 10x to 30x faster than Rollup, with the gap widening as project size grows. The Register picked up on the claim back in March 2026, when Vite’s team first went public with the Rolldown transition and the same order-of-magnitude figures, as reported by The Register. Those are vendor-sourced numbers, not an independent lab test, so treat the top end of that range as a best case rather than a guarantee for every codebase.
Is Rolldown Actually Stable Yet?
Yes, and that’s the detail worth underlining. Rolldown spent over a year as an experimental opt-in inside Vite before reaching 1.0. As of this week it’s on version 1.2.11, and VoidZero’s release notes for its combined “Vite Plus” bundle list Vite at 8.3.0 paired with Rolldown 1.2.8, while the standalone Vite package on npm has already moved to 8.3.1. That’s a tight, active release cadence, not an abandoned side branch. If you’re running an older Vite project, the shift to Vite 8’s Rolldown pipeline is now the default path forward rather than an experiment you opt into.
Oxc: The Other Half of Vite’s Rust Rewrite
Rolldown doesn’t work alone. VoidZero pairs it with Oxc, a Rust-based JavaScript and TypeScript parser, transformer, and linter that handles the syntax-level work before Rolldown ever touches a module graph. Together, Rolldown and Oxc form what VoidZero describes as a largely Rust-based pipeline from source file to final bundle, which is a meaningful departure from Vite’s original design. The original Vite still shelled out to esbuild for dependency pre-bundling and left production output to Rollup, a pure JavaScript tool. Vite 8 collapses that split: both the fast development path and the production build path now run through the same Rust core, which is part of why the performance gap over the old Rollup-based pipeline is as large as VoidZero claims.
For day-to-day development, this shows up less as a single dramatic speedup and more as consistency. Teams running large component libraries or monorepos with hundreds of packages tend to notice the difference most, since that’s exactly the scenario where a JavaScript-based bundler’s single-threaded parsing becomes the bottleneck. Smaller apps with a few dozen modules may not feel much difference at all, because the build was already fast enough not to matter. Bundle-size-sensitive teams already comparing lightweight dependencies, the same way a schema validation library comparison weighs output size against features, will recognize the pattern: a smaller, faster core doesn’t help much until a project is large enough to feel the difference.
Rspack: ByteDance’s Webpack-Compatible Rust Bundler
Rspack takes a different bet entirely. Instead of asking teams to adopt a new plugin API, it tries to run existing webpack configuration files with minimal changes. The project lives under the web-infra-dev organization on GitHub, ByteDance’s public home for its front-end infrastructure work, and its core package sits at version 2.2.8 on npm as of this week.
Compatibility is the whole pitch. Rspack supports webpack-style module resolution, most common loaders, a wide slice of the plugin ecosystem, and Module Federation, the mechanism large organizations use to split a single app into independently deployed microfrontends. That last piece is Rspack’s strongest differentiator: neither Vite/Rolldown nor Turbopack treats Module Federation as a first-class use case the way Rspack does, which is exactly what you’d expect from a bundler built inside a company running thousands of internal web properties.
The trade-off is that compatibility isn’t total. Plugins that reach into webpack’s undocumented internals, or depend on exact JavaScript-level compiler behavior, can still break under Rspack. A project can compile cleanly and still produce different chunk names, asset URLs, or CSS extraction behavior than the original webpack build. Teams migrating large codebases should budget time for that kind of output diffing rather than assuming a drop-in swap.
Turbopack: Vercel’s Bundler Built Into Next.js 16
Turbopack isn’t trying to be a general-purpose bundler at all. Vercel built it specifically for Next.js, and Next.js’s own documentation confirms Turbopack became the default bundler starting at Next.js 16.0.0. The framework has since moved on to 16.3.6, with Turbopack shipping inside every release rather than as a separate package most developers install directly, which is why its standalone npm package logs a mere 368 weekly downloads while the `next` package itself pulls in more than 67.8 million.
The architecture leans on incremental, demand-driven compilation: Turbopack only rebuilds the parts of the dependency graph that actually changed, and it caches aggressively between runs. That design shows up directly in Vercel’s own performance story, and in Next.js’s 16.0 release notes, where production build stabilization was one of the headline changes alongside the default-bundler switch.
The catch is coupling. Turbopack is optimized around Next.js’s compiler, its routing system, React Server Components, and its specific CSS handling. It isn’t positioned as a webpack replacement for a generic Express app or a standalone React SPA. If your stack isn’t Next.js, Turbopack mostly isn’t an option worth evaluating.
Full Specs Comparison: Vite 8 vs Rspack vs Turbopack
Here’s the side-by-side breakdown, current as of September 28, 2026:
| Spec | Vite 8 (Rolldown) | Rspack | Turbopack |
|---|---|---|---|
| Maintainer / backer | VoidZero | ByteDance (web-infra-dev) | Vercel |
| Core language | Rust (Rolldown + Oxc) | Rust | Rust |
| Latest version (npm, Sept 28, 2026) | Vite 8.3.1 / Rolldown 1.2.11 | @rspack/core 2.2.8 | Bundled in Next.js 16.3.6 |
| 1.0 / stable milestone | Rolldown 1.0, May 7, 2026 | Stable, ongoing releases | Default since Next.js 16.0.0 |
| License | MIT | MIT | Proprietary to Next.js, free to use |
| Standalone / framework-agnostic | Yes | Yes | No, tied to Next.js |
| Primary compatibility target | Rollup / Vite plugin API | Webpack loaders and plugins | Next.js config surface |
| Module Federation support | Via community/framework plugins | First-class, strong support | Limited, Next.js-specific |
| GitHub stars (live, Sept 28, 2026) | 83,062 (vitejs/vite) | 12,931 (web-infra-dev/rspack) | Part of vercel/next.js (142,842) |
| npm weekly downloads | 208,347,325 (vite) | 10,002,003 (@rspack/core) | 67,834,975 (next) |
| Best-known use case | Vue, Svelte, Solid, general SPA dev | Large webpack migrations, microfrontends | Next.js App Router apps |
| Dev server model | Native ESM dev server | Bundled dev/prod pipeline (webpack-style) | Incremental, demand-driven |
A few things jump out immediately. Vite pulls in roughly 20 times the weekly npm downloads of Rspack’s core package, and Next.js dwarfs both Rspack and Rolldown’s standalone repo in GitHub stars, but that’s a framework popularity signal as much as a bundler one. Rspack’s Module Federation support remains its clearest structural advantage over the other two.
Benchmark Data: Build Times, Cold Starts, and HMR Speed
No single lab has run all three bundlers against the same codebase on the same machine, so treat every number below as a data point from its own source rather than one unified leaderboard. Here’s what’s actually published.
VoidZero’s Official Rolldown vs. Rollup Claim
VoidZero’s own benchmarks, published alongside the Rolldown 1.0 announcement, put Rolldown at 10x to 30x faster than Rollup, with the advantage growing on larger dependency graphs, and roughly on par with esbuild’s raw speed. This is a vendor-published figure rather than an independently reproduced one, which is worth keeping in mind before quoting it as gospel in a planning document.
Third-Party Turbopack vs. Webpack Numbers
A Next.js performance guide from nextjslaunchpad.com measured a roughly 5,000-module application and reported cold development startup dropping from about 14 seconds under webpack to about 1.8 seconds under Turbopack, a 7.8x improvement. Hot module replacement after editing a leaf component fell from roughly 700 milliseconds to about 60 milliseconds, an 11.7x gain. Those are the most concrete third-party numbers available for Turbopack against its predecessor.
Vite vs. Next.js/Turbopack Production Build Comparison
A separate build comparison published at learning-center-snowy.vercel.app clocked a Vite 8.1.4 production build at roughly 3.5 seconds, against a Next.js/Turbopack build of about 8.3 seconds cold and 4.9 seconds warm on the same test project. That gap is expected: Next.js’s build includes server-side compilation, route manifests, and React Server Component processing that a plain Vite SPA build never touches, so the two numbers describe different jobs even though they look comparable on paper.
| Benchmark | Result | Source |
|---|---|---|
| Rolldown vs. Rollup build speed | 10x–30x faster (vendor claim) | VoidZero, May 2026 |
| Turbopack vs. webpack cold start (~5,000 modules) | ~14s → ~1.8s (7.8x) | nextjslaunchpad.com |
| Turbopack vs. webpack HMR (leaf component) | ~700ms → ~60ms (11.7x) | nextjslaunchpad.com |
| Vite 8.1.4 vs. Next.js/Turbopack production build | ~3.5s vs. ~8.3s cold / ~4.9s warm | learning-center-snowy.vercel.app |
Developer Experience: HMR, Error Overlays, and Debugging
Raw build speed gets the headlines, but the day-to-day experience of a bundler is shaped just as much by how it handles the small stuff: how fast a saved file shows up in the browser, how readable the error overlay is when something breaks, and how much configuration you have to write before the tool gets out of your way.
Vite’s dev server has been its calling card since the original release, and Vite 8 keeps that native ESM approach unchanged even though production bundling moved to Rolldown. The dev server still serves modules directly over native ES modules in the browser rather than pre-bundling the entire app, so most projects see near-instant hot module replacement regardless of overall app size. That part of Vite’s architecture was never the slow piece, and Rolldown’s contribution is almost entirely on the production build side.
Rspack takes the opposite approach by design, since its whole premise is staying close to webpack’s bundled dev-server model rather than switching to native ESM. That’s a deliberate trade-off: teams get a dev server that behaves like the webpack one they already know, at the cost of losing some of the raw HMR speed that a native-ESM tool like Vite offers on very large applications. For teams mid-migration from webpack, that familiarity is often worth more than a marginal HMR speed difference, since it means fewer surprises in day-to-day debugging.
Turbopack leans hardest into incremental computation. Rather than rebuilding a full dependency subtree on every save, it tracks a fine-grained graph of what actually changed and reuses cached work for everything else, which is the architectural reason behind the roughly 60-millisecond leaf-component HMR figure reported by the third-party Next.js benchmark referenced above. The trade-off is that this caching model is tightly bound to Next.js’s own compiler pipeline, so it doesn’t transfer to non-Next.js projects even in theory.
npm Downloads and GitHub Stars: Measuring Real Adoption
Stars and downloads don’t measure code quality, but they do measure how many teams have already bet on a tool, and that matters when you’re choosing what to depend on for the next few years. Pulled directly from the npm registry and GitHub’s API for the week of September 21 to 27, 2026:
| Package / repo | Weekly npm downloads | GitHub stars |
|---|---|---|
| vite | 208,347,325 | 83,062 |
| esbuild | 324,847,644 | N/A |
| rollup | 140,333,279 | N/A |
| rolldown | 113,678,951 | 13,956 |
| webpack | 63,273,291 | N/A |
| next | 67,834,975 | 142,842 |
| @rspack/core | 10,002,003 | 12,931 |
| turbopack (standalone pkg) | 368 | N/A |
The gap between vite’s 208 million weekly downloads and @rspack/core’s 10 million is roughly 20 to 1, but that’s not a fair one-to-one fight. Vite is a dependency of an enormous number of downstream frameworks and starter kits, many of which pull it in automatically. Rspack is still mostly a deliberate choice teams make when migrating off webpack, which is a smaller and more specific audience by definition. Esbuild’s 324.8 million weekly downloads are the real reminder here: a huge share of the JavaScript ecosystem depends on esbuild indirectly, since Vite, Rolldown-adjacent tooling, and dozens of other packages use it under the hood for lighter transform tasks even as Rolldown takes over Vite’s main bundling path.
Pricing and Commercial Backing
All three bundlers are free, open-source software under permissive licenses, so there’s no license fee comparison to make. What differs is who stands behind each one and what kind of support path exists if something breaks in production.
| Tool | License | Commercial backer | Support path |
|---|---|---|---|
| Vite 8 / Rolldown | MIT, free | VoidZero (dedicated tooling company) | Community + VoidZero’s commercial tooling ecosystem |
| Rspack | MIT, free | ByteDance (web-infra-dev team) | Community, GitHub issues; no published third-party enterprise SLA |
| Turbopack | Free to use, bundled with Next.js | Vercel | Tied to Vercel’s platform support tiers when hosted on Vercel |
None of these charge for the bundler itself. The real cost comparison is engineering time: Rspack markets itself on minimizing migration cost from webpack, Vite/Rolldown minimizes it for teams already on Vite or Rollup, and Turbopack’s “cost” is really the decision to build on Next.js in the first place, since you get Turbopack automatically once you do.
It’s worth separating the bundler’s price tag from the platform costs that sometimes get bundled into the conversation. Running Vite or Rspack doesn’t require any particular hosting provider, so teams can deploy the output to whatever static host, CDN, or server infrastructure they already use without paying anyone beyond their existing hosting bill. Turbopack is different only in that it ships inside Next.js, and Next.js apps are commonly deployed to Vercel’s own platform, which has its own separate pricing structure for compute, bandwidth, and team seats. That’s not a Turbopack cost. It’s a hosting decision that happens to be easy to make once you’ve already chosen Next.js, and plenty of teams run Next.js and Turbopack on other infrastructure entirely, including self-hosted Node servers and other cloud providers.
Real-World Adoption: Who’s Actually Using Each Bundler
Numbers on a registry only tell part of the story. Here’s where each bundler shows up in practice:
- Vue and the Vue ecosystem: Vue’s official tooling has been Vite-first for years, and that default carries forward into the Rolldown-powered Vite 8 without any framework-level opt-out needed.
- Svelte and SvelteKit: SvelteKit’s build pipeline runs on Vite, meaning every SvelteKit project inherits Rolldown’s production bundling the moment it upgrades to Vite 8. Test runners in the same ecosystem, like the ones weighed in our Vitest vs. Jest comparison, share that same Vite-first dependency chain.
- ByteDance’s internal web platforms: Rspack was built inside ByteDance’s web infrastructure org specifically to migrate large internal webpack codebases without a full rewrite, and it remains the reference example of Rspack at scale.
- Next.js App Router applications: Any team running Next.js 16 or later gets Turbopack as the default bundler with no separate installation step, per Next.js’s own Turbopack documentation.
- Microfrontend architectures on webpack: Organizations running Module Federation across dozens of independently deployed frontend apps are Rspack’s core migration audience, since that’s the one capability neither Vite/Rolldown nor Turbopack treats as a first-class feature.
The pattern is consistent: Vite/Rolldown wins by default inheritance through frameworks that already picked Vite, Turbopack wins by default inheritance through Next.js, and Rspack wins through deliberate, cost-driven migration decisions at organizations with large existing webpack investments.
That inheritance pattern is worth sitting with for a moment, because it explains why comparing raw adoption numbers across the three tools can be misleading. A team that picks SvelteKit for its routing model and component syntax never actually evaluates Vite as a bundler in isolation. They get Rolldown’s production build the moment they upgrade past Vite 8, without ever running a bake-off against Rspack or Turbopack. The same is true in reverse for Next.js: choosing the framework for its App Router and React Server Components support means Turbopack arrives as a package deal, not a separate procurement decision. Rspack is the outlier precisely because it’s usually adopted through deliberate technical evaluation rather than default inheritance, which is a slower, more intentional path to adoption but tends to produce a more committed user base once a team makes the switch.
Migration Guide: Moving From Webpack or Legacy Vite
The right migration path depends entirely on what you’re running today. Here’s the practical route for each starting point.
From Webpack to Rspack
This is the most direct swap of the three. Start by installing the Rspack CLI alongside your existing webpack config, then point it at the same entry file:
npm install --save-dev @rspack/core @rspack/cli
npx rspack build --config webpack.config.jsFrom there, work through loaders and plugins one at a time. Standard loaders like babel-loader, css-loader, and sass-loader tend to work with little or no change. Anything that reaches into webpack’s compiler internals, or depends on an undocumented hook, needs a manual check. Pay particular attention to Module Federation configuration, asset naming, and CSS extraction output, since those are the areas most likely to diverge silently even when the build succeeds without errors.
A practical rollout plan for a team migrating a production app: run Rspack and webpack side by side in CI for at least one release cycle, diffing the output bundles rather than just checking that the build exits with a zero status code. Set up automated checks comparing chunk counts, total bundle size, and asset hashes between the two builds. Differences under a few percent in bundle size are normal and usually come down to minifier version differences. Larger swings usually point to a plugin that isn’t behaving identically, and that’s worth catching in CI rather than in a user-facing regression after deployment. Teams with Module Federation setups should test every remote and host combination explicitly, since federation bugs tend to surface only when two independently deployed bundles try to share a module at runtime.
From Older Vite/Rollup to Vite 8
Bump your Vite dependency and Rolldown takes over production bundling automatically, since it’s the default in Vite 8 rather than an opt-in flag:
npm install vite@latest
npm run buildThe riskiest area is custom Rollup plugins that reach into internal hooks like resolve, load, transform, or renderChunk in non-standard ways. Rolldown targets Rollup-plugin-API compatibility, not byte-for-byte internal behavior, so test your chunking output, CommonJS interop, and library-mode builds before shipping the upgrade to production. Teams already covered by a Vite vs. webpack migration should find this second hop considerably smaller than the first one.
From Webpack to Turbopack (via Next.js)
This isn’t really a bundler migration so much as a Next.js version upgrade. Update to Next.js 16 or later and Turbopack becomes the default automatically:
npm install next@latest react@latest react-dom@latest
npm run devCustom webpack configuration in next.config.js is not automatically portable, so audit any manual webpack hooks, aliases, or loaders first. If your project has a Babel configuration file present, Next.js falls back to supporting it automatically, but native modules, unusual loaders, and unsupported plugin patterns may require you to stay on the legacy webpack path for that specific route until you can rework the dependency.
The lowest-risk way to validate the switch is to run next dev --turbopack against a staging branch before touching any production deploy pipeline, then compare page load behavior, CSS ordering, and any dynamic import boundaries against the webpack build. Teams with heavy use of custom webpack plugins for things like SVG transforms, worker loaders, or WASM imports should check Next.js’s supported-plugin list before migrating, since that surface is narrower than webpack’s full plugin ecosystem by design.
Vite 8 + Rolldown: Pros and Cons
| Pros | Cons |
|---|---|
| Rolldown now stable (1.0 since May 2026), no longer experimental | Some Rollup plugins relying on internal behavior may need updates |
| Framework-agnostic, works with Vue, Svelte, Solid, React SPAs | Not the strongest option for large legacy webpack Module Federation setups |
| Vendor-claimed 10x–30x speed gain over Rollup | That figure is vendor-published, not independently reproduced |
| Massive existing install base (208M+ weekly npm downloads) | Rolldown itself is newer and has a smaller dedicated star count than Vite |
Rspack: Pros and Cons
| Pros | Cons |
|---|---|
| Strongest webpack config and loader compatibility of the three | Smallest npm download footprint of the three (10M/week for @rspack/core) |
| First-class Module Federation support | No published third-party enterprise support SLA |
| Backed by ByteDance’s production web infrastructure needs | Complex or obscure webpack plugins can still fail to port cleanly |
| Rust performance without abandoning the webpack mental model | Less compelling if your app never needed webpack’s complexity to begin with |
Turbopack: Pros and Cons
| Pros | Cons |
|---|---|
| Zero-setup default in Next.js 16+, no separate install | Only usable inside the Next.js framework |
| Reported 7.8x faster cold start, 11.7x faster HMR vs. webpack | Those figures come from a third-party guide, not a controlled multi-vendor test |
| Deep integration with React Server Components and App Router | Custom webpack config in next.config.js isn’t automatically portable |
| Backed by Vercel, actively developed alongside Next.js core | Not a candidate at all for non-Next.js projects |
Which Bundler Fits Your Project? Five Use-Case Recommendations
- New Vue, Svelte, or Solid project: Pick Vite 8. Rolldown is already the default bundling engine and requires no extra configuration decisions.
- New Next.js 16 application: You’ll get Turbopack automatically. There’s no separate decision to make unless you have a specific reason to force the legacy webpack path.
- Large existing webpack app with Module Federation: Rspack is the strongest fit, since it’s the only one of the three built around preserving webpack’s loader and plugin model at scale.
- Standalone React SPA not using Next.js: Vite 8 with Rolldown is the more natural choice than trying to extract Turbopack from its Next.js dependency, which isn’t practically possible outside the framework.
- Monorepo with mixed framework targets: Consider Rspack if multiple packages still depend on webpack-specific plugins, or Vite 8 if the monorepo is already Vite-centric across its packages; forcing a single bundler onto a genuinely mixed monorepo often costs more engineering time than it saves.
Ecosystem and Plugin Compatibility: What Actually Breaks
Benchmarks get attention, but plugin compatibility is what actually determines whether a migration ships on schedule. Each of these three tools draws its compatibility line in a different place, and understanding exactly where that line sits saves a lot of debugging time later.
Rolldown’s compatibility promise is scoped to the Rollup plugin API, which means Vite plugins written against Vite’s own plugin hooks, and Rollup plugins written against the standard resolve/load/transform/renderChunk lifecycle, generally carry over without modification. Where things get uncertain is plugins that inspect Rollup’s internal output structures directly, or that were written years ago against Rollup behavior that was never formally part of the public API. Popular, actively maintained plugins in the Vite ecosystem have mostly already been updated for Rolldown compatibility given how long the tool spent in public beta before reaching 1.0, but smaller or abandoned plugins are the ones worth testing explicitly before an upgrade.
Rspack’s compatibility surface is the widest of the three by design, covering the bulk of webpack’s loader and plugin ecosystem including community favorites for asset handling, code splitting, and CSS extraction. The gaps tend to show up in plugins built for very specific webpack internals, like ones that patch the compiler’s module factory directly, or depend on webpack’s exact stats output format for custom reporting tooling. Module Federation is the one area where Rspack doesn’t just match webpack, it’s often held up as the reference implementation teams reach for specifically because of that support.
Turbopack’s plugin surface is the narrowest, and that’s intentional. Next.js exposes a defined, documented set of configuration options and supported loaders rather than an open plugin architecture the way webpack and Rspack do. That’s a trade-off in the other direction: less flexibility, but also less risk of an obscure third-party plugin silently breaking a build after a minor version bump, since there are simply fewer moving parts for something to go wrong in.
The Verdict: What the Data Actually Says
There isn’t a single winner here, and that’s the honest conclusion after looking at the download counts, star counts, and benchmark claims side by side. Vite 8 with Rolldown has the largest install base by a wide margin, at 208.3 million weekly npm downloads against Rspack’s 10 million, and it’s the safest default for any framework-agnostic frontend project that isn’t buried in webpack-specific configuration. Turbopack’s numbers are the most dramatic in isolated benchmarks, with a reported 7.8x faster cold start and 11.7x faster HMR against webpack, but that speed only matters if you’re already building on Next.js, since the tool doesn’t exist independently of the framework.
Rspack remains the correct call for one specific, high-value scenario: large organizations with existing webpack investments, particularly ones using Module Federation for microfrontends, who need Rust-level speed without rewriting their plugin stack. Its 12,931 GitHub stars and 10 million weekly downloads look modest next to Vite’s numbers, but that reflects a smaller, more deliberate target audience rather than a weaker product.
If you’re starting fresh in 2026 and have no framework constraint pulling you toward Next.js, Vite 8 is the default worth defaulting to. If you’re already on Next.js, Turbopack comes with the territory. And if webpack is deeply embedded in your build pipeline and rewriting it isn’t realistic this year, Rspack is built specifically for that migration.
Frequently Asked Questions
Is Rolldown replacing Rollup completely in Vite 8?
Rolldown is now Vite 8’s default production bundler, replacing Rollup in that role. Rollup itself remains an active, separate open-source project maintained outside of Vite, and some tooling outside the Vite ecosystem still uses it directly.
Can I use Turbopack outside of Next.js?
Not in any practical, supported way. Turbopack is built and distributed as part of the Next.js toolchain, and its standalone npm package logs only a few hundred weekly downloads, reflecting that almost nobody installs it independently of the framework.
Does Rspack support every webpack plugin?
No. Rspack supports most common loaders and plugins, but anything that depends on webpack’s undocumented internals or exact JavaScript-level compiler behavior can still break. Teams should test output like chunk naming and CSS extraction after migrating rather than assuming a clean build means identical behavior.
Which bundler has the most GitHub stars?
Among the standalone bundler repositories, vitejs/vite leads with 83,062 stars as of September 28, 2026, ahead of rolldown/rolldown at 13,956 and web-infra-dev/rspack at 12,931. Turbopack doesn’t have its own separate repository, since it’s built inside the vercel/next.js monorepo, which itself carries 142,842 stars.
Is Rspack only useful for ByteDance-style large companies?
No, but its strongest use case is exactly that profile: large webpack codebases, often with Module Federation microfrontends, where a full rewrite to a new plugin API isn’t realistic. Smaller projects without heavy webpack investment generally get more value from Vite 8 instead.
Do I need to rewrite my Vite plugins to use Rolldown?
Most standard Vite and Rollup plugins should keep working, since Rolldown targets compatibility with the Rollup plugin API. Plugins that call undocumented internal hooks or depend on Rollup-specific implementation quirks are the ones most likely to need updates after upgrading to Vite 8.
Are all three bundlers really free to use commercially?
Yes. Vite, Rolldown, and Rspack ship under the MIT license, and Turbopack is free to use as part of Next.js. None of the three charge a licensing fee for the bundler itself, though Turbopack’s practical cost is tied to choosing Next.js and, if you host there, Vercel’s own platform pricing.
Which one should I pick if I’m just starting to learn frontend build tools?
Vite 8 is the most approachable starting point. It has the largest community, the most tutorials and framework integrations, and Rolldown’s speed gains happen automatically without requiring you to understand webpack’s configuration model first. Pairing it with a modern editor setup, such as the workflow covered in our 2026 code editor comparison, gets a new project running with sensible defaults in minutes rather than hours.
Can I run Rspack and webpack side by side during a migration?
Yes, and it’s the recommended approach for any production application. Running both build pipelines in parallel through CI, and diffing chunk counts, bundle sizes, and asset output between them, catches silent behavioral differences before they reach users. Treat a clean Rspack build as a starting point for verification, not proof that the migration is complete.
Does switching to Rolldown, Rspack, or Turbopack change my application’s runtime behavior?
It shouldn’t, and that’s the goal of all three projects: change how fast the code compiles, not what the code does once it’s running in the browser. In practice, edge cases around module resolution order, tree-shaking of side-effectful code, and CSS specificity from extraction plugins are the most common sources of behavioral drift after a bundler migration, which is why testing real user flows after switching, not just confirming the build succeeds, matters for all three tools.
