Rspack vs Webpack in 2026: The Rust-Powered Drop-In Replacement

TL;DR

Rspack is production-ready and genuinely faster — but "drop-in replacement" is aspirational. Rspack (~800K weekly downloads) achieves 5-10x faster builds than webpack by rewriting the core in Rust. Webpack (14M+ weekly downloads) has 15 years of plugins and documentation. Most webpack configs migrate in hours, not weeks. If you have a large webpack project with slow builds, Rspack is worth evaluating. If your webpack builds are already fast, stay.

Key Takeaways

Webpack: ~14M weekly downloads — Rspack: ~800K (npm, March 2026)
Rspack builds 5-10x faster — ByteDance's internal data: 90% compilation time reduction
~80% webpack plugin compatibility — most common plugins work; obscure ones may not
Rspack 1.0 is stable (2024) — production-ready, backed by ByteDance
Configuration is identical — webpack.config.js mostly becomes rspack.config.js directly

The Context

Webpack revolutionized JavaScript bundling in 2014. By 2024, webpack 5 is a mature, stable tool that powers millions of projects. The problem: webpack is written in JavaScript and fundamentally limited in how fast it can parallelize work.

Rspack solves this by rewriting webpack's core in Rust, using multi-threading throughout, and keeping the same configuration API. It was built by ByteDance (TikTok's parent company) to speed up their massive frontend monorepo, then open-sourced.

Configuration Comparison

// webpack.config.js — typical config
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  entry: './src/index.tsx',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash].js',
    clean: true,
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, 'css-loader', 'postcss-loader'],
      },
    ],
  },
  plugins: [
    new HtmlWebpackPlugin({ template: './public/index.html' }),
    new MiniCssExtractPlugin({ filename: '[name].[contenthash].css' }),
  ],
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
};

// rspack.config.js — nearly identical
const path = require('path');
const { HtmlRspackPlugin } = require('@rspack/core');

module.exports = {
  entry: './src/index.tsx',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash].js',
    clean: true,
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        // No ts-loader needed — built-in SWC transpilation
        type: 'javascript/auto',
        use: {
          loader: 'builtin:swc-loader',
          options: { jsc: { parser: { syntax: 'typescript', tsx: true } } },
        },
      },
      {
        test: /\.css$/,
        // Built-in CSS extraction (no mini-css-extract needed)
        type: 'css/auto',
      },
    ],
  },
  plugins: [
    new HtmlRspackPlugin({ template: './public/index.html' }),
  ],
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
};

Key differences in practice:

Replace ts-loader with builtin:swc-loader (or remove it — TypeScript support is built-in)
Replace mini-css-extract-plugin with type: 'css/auto'
Use HtmlRspackPlugin instead of HtmlWebpackPlugin (or the webpack plugin still works)

Performance Benchmarks

Rspack's official benchmarks on a project with 10,000 modules:

Metric	webpack 5	Rspack
Cold build	24.6s	3.4s (7.2x)
Incremental build	2.1s	0.2s (10.5x)
Cold build (minified)	42.1s	7.2s (5.8x)

Real-world results are lower but still significant:

Small projects (< 1000 modules): 2-3x faster
Medium projects: 4-6x faster
Large projects (1000+ modules): 7-10x faster

Plugin Compatibility

// These common plugins work with Rspack:
// ✅ html-webpack-plugin
// ✅ copy-webpack-plugin
// ✅ css-loader, postcss-loader
// ✅ babel-loader
// ✅ image optimization plugins
// ✅ DefinePlugin (built-in)
// ✅ EnvironmentPlugin

// These may have issues:
// ⚠️ Some code coverage plugins (e.g., istanbul)
// ⚠️ Unusual custom loaders with internal webpack API access
// ⚠️ fork-ts-checker-webpack-plugin (use builtin:swc-loader instead)
// ❌ Plugins that access internal webpack graph APIs directly

Migration Guide (Typical Project)

# 1. Replace webpack with Rspack
npm remove webpack webpack-cli
npm install --save-dev @rspack/core @rspack/cli

# 2. Update package.json scripts
# "build": "webpack" → "build": "rspack build"
# "dev": "webpack serve" → "dev": "rspack serve"

# 3. Rename config
# webpack.config.js → rspack.config.js

# 4. Update config (minimal changes usually)
# - Replace ts-loader with builtin:swc-loader (or keep babel-loader)
# - Replace mini-css-extract-plugin with type: 'css/auto'
# - Update HTML plugin import

# 5. Run and fix issues
rspack build --profile

Most projects report 2-4 hour migration time for a medium-complexity webpack config.

When to Migrate

Strong candidates for Rspack migration:

Build times > 30 seconds (the ROI is immediate)
Large TypeScript projects (Rspack's built-in SWC transpilation replaces ts-loader)
You have time to test the migration (not mid-feature)
Mostly use popular plugins in the webpack ecosystem

Stay on webpack:

Build times already < 5 seconds (the pain isn't there)
You use webpack plugins that depend on internal webpack APIs
You can't afford migration risk in a critical period
You're considering switching to Vite anyway (different architecture, better ecosystem long-term)

Compare Rspack and webpack package health on PkgPulse.