Rspack 2.0 vs Rolldown: the 2026 migration decision for a legacy Webpack app

Summary. Two Rust bundlers reached maturity within six weeks of each other in 2026. Vite 8 shipped on 12 March 2026 with Rolldown as its single bundler, replacing both esbuild and Rollup, and Rolldown itself reached 1.0 on 7 May 2026. Rspack 2.0 shipped on 22 April 2026 from ByteDance, holding its webpack API compatibility. The published performance claims are not comparable: Rolldown is benchmarked at 10 to 30 times faster than Rollup, while Rspack 2.0 is benchmarked at about 10% faster than Rspack 1.7 and up to 100% faster than Rspack 1.0. Neither project publishes a head-to-head number against the other. Adoption differs by roughly 20 times, with Vite passing 100 million weekly downloads by June 2026 against Rspack's 5 million, up from 100,000 at its 1.0 release in August 2024. And ownership changed underneath one of them: VoidZero, which builds Vite and Rolldown, was acquired by Cloudflare on 4 June 2026, with a $1 million ecosystem fund attached. For a legacy Webpack application, the deciding factor is not build speed. It is whether you are migrating a build or rebuilding an application.

The choice in one sentence

Rspack asks you to change your bundler. Vite 8 asks you to change your architecture.

That is the whole decision, and every other consideration is downstream of it. Rspack was built to accept webpack's configuration shape, loaders and plugin API, so a migration is mostly a dependency swap plus a shortlist of breaking changes. Vite has never accepted webpack configuration. It uses the Rollup plugin API, a native ESM development server, and a different mental model for assets, aliases and code splitting. Moving a mature Webpack application to Vite 8 means rewriting the build layer and, usually, touching application code.

Both projects state their positions clearly. The Rspack team wrote in the 2.0 announcement that "Rspack's goal is not just to be a faster webpack", while confirming in the same post that "in the 2.0 era, compatibility with the webpack ecosystem will remain an important goal for Rspack". Vite made the opposite trade deliberately: it built a compatibility layer that auto-converts existing esbuild and rollupOptions configuration to Rolldown and Oxc equivalents, so most Vite projects upgrade without config changes. That layer helps existing Vite users. It does nothing for a Webpack user.

What each project actually shipped

The two headline benchmarks measure different things against different baselines. Rspack's figures come from a 10,000-component React project and compare Rspack against earlier Rspack. Rolldown's 10 to 30 times figure compares Rolldown against Rollup, which was never the bundler your Webpack application was using. An InfoQ report on the Rspack 2.0 release noted the same limitation from the community side, quoting an r/rust reader who observed that the benchmarks only compare against older Rspack versions.

So neither number tells you what your build will do. Treat both as evidence that Rust-based bundling is fast, and nothing more.

The numbers that are actually usable

Vite's release notes carry something better than a synthetic benchmark: production build times reported by named companies during the rolldown-vite preview and the Vite 8 beta.

Rspack's equivalent evidence is its own benchmark table on a 10,000-component React project, which is at least reproducible because the harness is public.

Two details in that table matter more than the headline. Persistent cache is doing most of the work: 3.1 seconds cold against 1.4 seconds warm. And hot module replacement barely moved across two major versions, from 128 ms to 118 ms, because HMR was already fast enough that the bundler is no longer the bottleneck.

The CI cost math nobody runs

Faster builds are usually sold as a CI saving. On GitHub-hosted runners, that claim is often wrong, and the reason is in GitHub's own billing reference: "GitHub rounds the minutes and partial minutes each job uses up to the nearest whole minute."

Published Linux rates as of August 2026 are $0.006 per minute for a standard 2-core x64 runner, $0.012 for a 4-core larger runner, $0.022 for 8-core and $0.042 for 16-core.

Now apply the rounding rule to Linear's reported result. A build going from 46 seconds to 6 seconds is a 40-second saving in wall-clock time and a zero-minute saving on the invoice, because both durations round up to one billed minute. The engineer waiting on it gets 40 seconds back. Finance sees nothing.

The saving only appears once builds cross minute boundaries. Take a 12-minute production build on an 8-core Linux runner at $0.022 per minute, which costs $0.264 per run. Apply Beehiiv's reported 64% reduction and it becomes 4.32 minutes, billed as 5 minutes, or $0.11 per run. That is $0.154 saved per build. At 300 builds a day across 22 working days, roughly 6,600 builds, the monthly saving is about $1,016.

The pattern is clear. Below roughly two minutes, a bundler swap is a developer-experience project, not a cost project. Above ten minutes, it starts to pay for itself. Work out which one you are before you write the business case. If your builds are already short and your pain is CI queue time rather than build time, persistent build caching in your existing pipeline is the cheaper fix, and the same applies to the Turbopack persistent build cache in CI.

Migration cost, honestly

Moving a Webpack app to Rspack

This is the shorter path by a wide margin, because the configuration survives. The known 2.0 breaking changes are specific and enumerable: Node.js 18 support is dropped in favour of a 20.19+ or 22.12+ floor, module.unsafeCache is removed, and @rspack/core, @rspack/cli, @rspack/dev-server and @rspack/plugin-react-refresh should be bumped together to ^2.0.0.

The larger change is that Rspack's core packages are now published as pure ESM, with their CommonJS builds removed. For most projects this is a non-event, because Node.js 20 and later can load ESM through require(). Projects that consume Rspack through the JavaScript API in a CommonJS build script are the exception worth checking first.

Rspack also ships a migration path for teams using coding agents. The 2.0 announcement documents an agent skill installed with a single command:

            npx skills add rstackjs/agent-skills --skill rspack-v2-upgrade
          

The dependency reduction in 2.0 is a second, quieter reason to move. @rspack/dev-server went from 192 npm dependencies to 1, and its install size fell from 15 MB to 1.4 MB, a reduction of more than 90%. @rspack/core went from 8 dependencies to 1, and @rspack/cli now has none. For anyone maintaining a software bill of materials or defending a supply-chain review, that is worth more than a percentage point of build speed.

Moving a Webpack app to Vite 8

Budget for a rebuild of the build layer. Webpack loaders do not transfer, webpack.config.js does not transfer, and code relying on require.context, webpack-specific magic comments or CommonJS-only dependency graphs needs rework. Vite's own migration advice is aimed at existing Vite users: switch from vite to the rolldown-vite package on Vite 7 first, then upgrade to Vite 8, so that Rolldown-specific issues surface separately from other Vite 8 changes. Useful advice, and not applicable to you if you are on Webpack today.

There is also an install-size cost that Vite documents openly. Vite 8 is approximately 15 MB larger than Vite 7, roughly 10 MB from making lightningcss a normal dependency rather than an optional peer, and roughly 5 MB from the Rolldown binary. That is the opposite direction to Rspack 2.0's dependency slimming, and it is a deliberate trade in favour of better out-of-the-box CSS minification.

What you get in exchange is a genuinely different development experience: a native ESM dev server, integrated Vite Devtools, built-in tsconfig paths support, emitDecoratorMetadata handled without a plugin, and browser console forwarding that pipes runtime client errors into the terminal, which Vite enables automatically when it detects a coding agent. An experimental Full Bundle Mode is also in progress, with preliminary results of 3 times faster dev server startup, 40% faster full reloads and 10 times fewer network requests.

Who owns the tool you are betting on

This is the factor most bundler comparisons skip, and in 2026 it moved.

Evan You, founder of VoidZero and creator of Vue and Vite, was direct about the commercial position in his 4 June 2026 announcement: "Despite the rapidly growing adoption of our tools, we haven't yet solved monetization. Monetizing tooling, especially open-source software, has proven to be quite challenging." VoidZero had experimented with a mixed licensing model for Vite+, abandoned it, released Vite+ under the MIT License, and then joined Cloudflare.

The commitments attached are specific. Vite, Vitest, Rolldown, Oxc and Vite+ stay open source and MIT-licensed, the VoidZero team continues to lead them, and Cloudflare committed $1 million to a Vite ecosystem fund administered by the Vite core team. You also wrote that "the most important condition for VoidZero to join any company was a full commitment to supporting all of our open-source projects in a way that respects their communities."

Rspack's governance is simpler and older: it is an MIT-licensed project maintained by ByteDance, sitting inside the broader Rstack toolchain alongside Rsbuild, Rslib, Rstest, Rspress, Rsdoctor and Rslint.

Neither arrangement is obviously safer. A single-vendor open-source project carries roadmap risk in both cases. The honest framing is that Rolldown now sits inside a public infrastructure company with an explicit interest in Vite apps deploying to its platform, and Rspack sits inside a private company with an explicit interest in its own product surface. Pick the incentive you would rather live with, and keep your build layer thin enough to leave either one.

A decision table you can actually use

India-specific considerations

For teams in India running offshore or GCC delivery models, the migration-cost asymmetry matters more than anywhere else, because the work is usually being estimated in engineer-days for a client.

An Rspack migration on a mature Webpack codebase is a scoped, testable engagement: swap the packages, work the enumerated breaking changes, verify output parity, measure. A Vite 8 migration on the same codebase is a build-layer rewrite whose true scope only becomes visible after the first week, when webpack-specific patterns in application code start surfacing. Quoting the second as if it were the first is how fixed-price front-end modernisation projects go wrong.

Two practical notes. First, the pure-ESM shift in Rspack 2.0 and the Node.js 18 drop both interact with older CI images that are still common on self-managed runners in India; check the Node version on your build agents before you check anything else. Second, if your roadmap already includes a TypeScript toolchain move, sequence it deliberately rather than bundling it with the bundler change, because two Rust-toolchain migrations in one release window make regressions impossible to attribute. The same sequencing argument applies to TypeScript 7 migration readiness and to the wider Rust and Go toolchain shift in Next.js. For the broader platform context these choices sit inside, see the Interop 2026 web platform developer guide.

What we would do

Run the swap on a branch and measure your own build before reading anyone else's benchmark. Both tools are fast enough that the published numbers are no longer the deciding input. The real cost is usually the migration, not the code.

If the answer is Rspack, treat it as a two-week engineering task with a hard parity gate: identical bundle contents, identical runtime behaviour under your existing test suite, and a measured build-time delta on your own CI runners rather than a vendor chart. If the answer is Vite 8, treat it as a quarter, not a sprint, and scope the application changes before the build changes.

And if your builds are already under two minutes, the honest recommendation is to do neither this quarter and spend the time on your test suite instead.

FAQ

How eCorpIT can help

eCorpIT runs build-tooling migrations as parity-gated engineering work: a branch-level swap, an identical-output check against your existing bundle, and a build-time measurement taken on your own CI runners before anyone signs off on a number. We are a CMMI Level 5 and ISO 27001:2022 certified organisation, and our senior engineering teams handle front-end platform work alongside the CI and supply-chain review that a bundler change triggers. If you are weighing Rspack against Vite 8 on a mature Webpack codebase, contact us for a scoped assessment of which one your code can actually absorb.

References

1. Vite 8.0 release announcement (12 March 2026)

1. Announcing Rspack 2.0 (22 April 2026)

1. Rolldown project site

1. Rspack project site

1. VoidZero is joining Cloudflare, by Evan You (4 June 2026)

1. Cloudflare announcement, VoidZero joins Cloudflare

1. InfoQ, Rspack 2.0: performance gains, leaner dependencies and ESM core (21 July 2026)

1. GitHub Docs, Actions runner pricing

1. Rspack 10,000-component React benchmark harness

1. Rolldown benchmarks repository

1. Rspack 1.x to 2.0 migration guide

1. Vite migration guide

1. Announcing Rolldown 1.0 (7 May 2026)

1. Oxc, the JavaScript toolchain in Rust

Last updated: 7 August 2026.