Rspack vs Webpack — Is the Rust Bundler Ready to Replace?
Rspack 2.0 is 5–18× faster at dev startup and 31× faster at HMR than webpack 5. Bundle output is identical. Most webpack projects should migrate.
By Ethan
1,433 words · 8 min read
If your webpack build is slow, switch to Rspack. Dev startup is 5–18× faster, HMR is 31× faster at scale, and production builds are 5–9× faster — all with the same webpack config and near-identical bundle output. Migration takes 1–2 days for a medium-sized app.
Who this is for
Teams running webpack 5 projects who are tired of waiting for builds. If you are starting a new project with no webpack history, read the verdict section first — Vite 8 may be the better default.
What we tested
Rspack v2.0.6 (released 2026-06-02) vs webpack 5.107.2. Both configured with SWC (not Babel) for apples-to-apples comparison. Benchmark data from rstackjs/build-tools-performance, GitHub Actions run 2026-06-01. App scales: react-1k (1,000 modules), react-5k, react-10k.
The numbers
The headline metric is HMR at scale: 31× faster at 5,000 modules — 105 ms vs 3,314 ms. For a developer who triggers dozens of saves per hour, that difference is the difference between a tight feedback loop and context-switching out to a browser tab.
Dev server startup (no cache)
| App scale | Rspack 2.0.6 | webpack 5.107 | Speedup |
|---|---|---|---|
| 1,000 modules | 1,566 ms | 9,135 ms | 5.8× |
| 5,000 modules | 901 ms | 14,189 ms | 15.7× |
| 10,000 modules | 1,476 ms | 26,984 ms | 18.3× |
Hot module replacement
| App scale | Rspack 2.0.6 | webpack 5.107 | Speedup |
|---|---|---|---|
| 1,000 modules | 163 ms | 736 ms | 4.5× |
| 5,000 modules | 105 ms | 3,314 ms | 31.6× |
| 10,000 modules | 156 ms | 3,386 ms | 21.7× |
Production build (no cache)
| App scale | Rspack 2.0.6 | webpack 5.107 | Speedup |
|---|---|---|---|
| 1,000 modules | 1,032 ms | 7,730 ms | 7.5× |
| 5,000 modules | 2,014 ms | 14,071 ms | 7.0× |
| 10,000 modules | 5,219 ms | 45,436 ms | 8.7× |
Memory usage (dev server RSS)
| App scale | Rspack 2.0.6 | webpack 5.107 | Rspack advantage |
|---|---|---|---|
| 1,000 modules | 347 MB | 822 MB | 2.4× less |
| 5,000 modules | 283 MB | 1,818 MB | 6.4× less |
| 10,000 modules | 355 MB | 1,923 MB | 5.4× less |
Bundle output
Bundle sizes are essentially identical. At react-10k: Rspack outputs 5,861 kB vs webpack’s 5,934 kB — a 1.2% difference. Gzipped sizes are within 0.1–1% across all scenarios. You do not trade output quality for build speed.
One note on the cached dev startup: webpack 5.107.2 at react-10k is slower with cache (27,569 ms) than without (26,984 ms), suggesting cache invalidation overhead that compounds at scale.
Compatibility
Rspack’s design goal is drop-in replacement for webpack 5. In practice, >80% of the top-50 webpack plugins work natively or with a maintained alternative.
Works without changes
28 widely-used plugins are fully compatible, including html-webpack-plugin, webpack-bundle-analyzer, terser-webpack-plugin, compression-webpack-plugin, @sentry/webpack-plugin (v1.20.1+), and @loadable/webpack-plugin. Almost all loaders work: babel-loader, css-loader, sass-loader, less-loader, vue-loader, svelte-loader.
Built-in replacements (identical config)
Some webpack plugins ship as built-ins in Rspack — drop in, no config changes:
| webpack | Rspack built-in |
|---|---|
copy-webpack-plugin | rspack.CopyRspackPlugin |
mini-css-extract-plugin | rspack.CssExtractRspackPlugin |
tsconfig-paths-webpack-plugin | resolve.tsConfig option |
circular-dependency-plugin | CircularDependencyRspackPlugin |
Drop-in alternatives
Three common plugins require a maintained Rspack-specific package:
| webpack | Rspack alternative |
|---|---|
eslint-webpack-plugin | eslint-rspack-plugin |
fork-ts-checker-webpack-plugin | ts-checker-rspack-plugin |
@pmmmwh/react-refresh-webpack-plugin | @rspack/plugin-react-refresh |
Not yet supported (8 plugins)
@cypress/webpack-preprocessor, critters-webpack-plugin, git-revision-webpack-plugin, webpack-remove-empty-scripts, and four others. See the full compatibility list. If your project depends on any of these, migration requires either a workaround or waiting for coverage.
Module Federation
Rspack ships first-class Module Federation support at two levels. MF 1.5 is a drop-in for existing federated webpack apps — same API. MF 2.0 (via @module-federation/enhanced) adds dynamic type hints, a Chrome DevTools extension, runtime plugins, and preloading. Interop between webpack hosts and Rspack remotes is supported, which makes incremental monorepo migration viable.
Migration
The mechanical steps are straightforward:
# 1. Swap packages
npm remove webpack webpack-cli webpack-dev-server
npm install -D @rspack/core @rspack/cli @rspack/dev-server
# 2. Rename config
mv webpack.config.js rspack.config.js
# 3. Update scripts in package.json
# "build": "webpack" → "build": "rspack build"
# "dev": "webpack serve" → "dev": "rspack serve"
# 4. Replace mini-css-extract-plugin with the built-in
# Remove the import; use rspack.CssExtractRspackPlugin instead
After that, swap babel-loader for the built-in builtin:swc-loader to pick up an additional 2–4× speed gain:
// rspack.config.js
{
test: /\.[jt]sx?$/,
use: [{
loader: 'builtin:swc-loader',
options: { jsc: { parser: { syntax: 'typescript', tsx: true } } }
}]
}
Watch for these friction points (all hit by Mews in their real-world migration):
- Dynamic imports with multiple string interpolations: SWC doesn’t support
import(\${dir}/${file}`)` with multiple interpolations. Requires refactoring the call site. - Styled Components SWC plugin:
swc_coreversion alignment between Rspack and the styled-components SWC plugin needs care — pin both and verify on upgrade. - Browserslist: the Rust implementation requires
BROWSERSLIST_DANGEROUS_EXTEND=trueas an env var if you’re extending configurations across packages. - Custom Babel transforms: Babel plugins have no direct Rspack equivalent. Rewrite as SWC plugins or standalone transforms.
Recommended rollout: pilot one non-critical app, validate outputs match (the bundle size numbers above confirm they should), then roll out to the rest. ByteDance runs Rspack internally across TikTok, Douyin, Lark, and Coze — the rollout path is well-worn.
For monorepos, Nx ships native Rspack support via @nx/rspack. It handles the per-app config wiring and lets you migrate one app at a time without touching the root build setup.
Verdict
Migrate if: your webpack builds are slow and none of your plugins are on the unsupported list. That covers most teams. The benchmarks are confirmed by independent runs and large-scale adopters including Microsoft, Amazon, Alibaba, and Discord. Bundle output is byte-for-byte comparable.
Wait if: your project depends on @cypress/webpack-preprocessor, critters-webpack-plugin, or another unsupported plugin and there is no viable alternative. Also wait if you have complex Babel transforms you cannot rewrite.
Skip webpack entirely if: you are starting a new project with no webpack history. Rspack is the right choice if you need webpack’s plugin surface. If you do not, Vite 8 (with Rolldown+Oxc) is faster at cold build on the popular-libs benchmark — 1,023 ms vs 1,668 ms — and produces slightly smaller bundles.
The Rust bundler is production-ready. As of Rspack 2.0 (April 2026), the question is not whether it works — 5 million weekly downloads and enterprise deployment at scale answer that. The question is whether your specific plugin list fits. For most projects, it does.
Summary
| Dimension | webpack 5.107 | Rspack 2.0.6 |
|---|---|---|
| Cold dev start (10k modules) | ~27s | ~1.5s (18×) |
| HMR (5k modules) | ~3.3s | ~105ms (31×) |
| Prod build (10k modules) | ~45s | ~5.2s (8.7×) |
| Dev memory (10k modules) | ~1.9 GB | ~355 MB (5.4×) |
| Bundle output size | ✅ | ✅ (≈ identical) |
| Config compatibility | Native | ~85% drop-in |
| Top-50 plugin support | Native | >80% (native/alt) |
| Module Federation | MF 1.x | MF 1.5 + 2.0 |
| npm downloads/week | >30M | ~5M |
Caveats
Rspack v2.0.6 benchmarks were run against Rspack 2.0.5 (one patch behind) — the benchmark repo had not updated when the data was collected on 2026-06-01. No functional differences between 2.0.5 and 2.0.6 affect the numbers.
In December 2024, the Rspack npm packages were briefly compromised with crypto-mining malware (The Hacker News). The incident was resolved within hours. All v1.1+ releases are clean. For security-sensitive deployments, pin versions and verify checksums in CI.
npm download comparisons between webpack (>30M/week) and Rspack (~5M/week) reflect webpack’s 15-year install base, not current adoption intent. The more meaningful signal: Rspack went from 100k/week at v1.0 (October 2024) to 5M/week at v2.0 (April 2026) — 50× growth in 18 months.
This article contains no affiliate links.
References
- Rspack — Announcing 2.0
- Rspack GitHub Releases — v2.0.6
- rstackjs/build-tools-performance — benchmark data, 2026-06-01
- Rspack Plugin Compatibility Guide
- Rspack Webpack Migration Guide
- Rspack Module Federation Docs
- Mews Engineering — Goodbye Webpack, Hello Rspack
- InfoQ — Rspack 1.0 Released, 23× Faster than Webpack
- The Hacker News — Rspack npm Supply Chain Attack (Dec 2024)
- Rspack — Trusted By (homepage adopters)
- Nx — @nx/rspack
- module-federation.io — Rspack integration