Switching from Webpack to Rspack

by

Webpack is a bundler and build system for frontend web apps. Webpack has been used to bundle React web apps and for many years was the default bundler and build system to use for that purpose. Later on, bundlers like vite (rollup and esbuild) were created that are more performant than webpack and are now the default when starting new React projects. The trouble is that switching from webpack to another build system such as vite requires much more work than optimizing the webpack configuration and plugins. For many teams, webpack was the only path forward, hoping and waiting that there would be performance optimizations in every update of webpack and the plugins for webpack.

One viable competitor has emerged: Rspack. It is a Rust-based build system for JavaScript and TypeScript web apps that is compatible with Webpack. Rspack works with many Webpack plugins and offers replacements for the major Webpack plugins. There is a documented migration path from Webpack to Rspack. By targeting compatibility with the major Webpack APIs, and with good documentation, Rspack reduced the complexity and the effort and made migration feasible.

Webpack Performance Issues

The search for a faster, better build system was started because of performance issues with webpack. The issues were the speed of compilation and the memory usage required. The team put time into researching and investigating the performance bottlenecks in webpack, and I have written about webpack build-time performance for React.

With newer MacBooks, the speed of webpack was faster due to the hardware. However, the React app was also being built and re-compiled within a Docker container. In the CI process, we could pay more to increase the memory available, and wait for webpack to finish the build. For a local MacBook Docker or cloud-based Linux development environment, the slowness affected the workflow of engineers. Due to a few plugins and a few cycle issues with imports, memory usage for a webpack build required a lot of RAM, up to 12 GB. For engineers, they would see a spike in memory usage, and subsequent iteratively compiled bundles had smaller spikes of memory usage. Many engineers opted for building the web app once and not having hot-reload available within Docker, or building it on the host machine which was slightly faster.

The variance in environments, from the latest MacBook Pros to Linux virtual machines with limited CPU and memory, required testing in each environment to measure the baseline performance. When we migrated to Rspack, testing each environment was a necessity to avoid regressions and to benchmark the performance of the build. In the CI/CD environment, we could check the CPU and memory usage across multiple jobs and workflows, along with the cost of the build/test run.

What are the benefits of Rspack?

Let’s begin with the technical outcomes. The technical outcomes of switching to Rspack:

  • Faster initial and iterative compilation
  • Lower memory usage

Now, the benefits of rspack:

  • Engineers can work on React web app features smoothly and iterate and deliver sooner
  • Designers, QA, product managers can try out and test features sooner
  • Lowers the cost of CI/CD service by reducing the memory required and shortening the build time

You may be wondering why I split the benefits into two. Well, it’s because the technical outcomes are usually what engineers state first, and they assume the conclusion that the technical outcomes are desirable and the effort is worthwhile. As an engineering manager, I like seeing the benefits that will lead to a business outcome, and the drawbacks that may affect other teams. The technical outcomes are what realize those benefits. The benefits show what the technical outcomes lead to. With a slower build system, engineers deliver slowly. With high memory usage, the costs of the CI/CD service are very high. By saving time and money we ship sooner and can re-allocate costs from CI/CD to another line item in the budget. Sometimes the benefit is enabling whole new features or even product lines because specific technical challenges were solved.

Planning and Implementing Rspack to replace Webpack

The planning process outlined the following:

  • Where we built and deployed the React web app (CI/CD, local and cloud-based development environments)
  • The set of webpack plugins we use as part of the build
  • What constituted a go-ahead in the prototyping phase
  • The test scenarios for a production rollout
  • How we could rollback to webpack in case of any issues
  • The stakeholders who would need to sign off on the change, from staff frontend engineers to QA to directors of engineering.

In the prototyping phase, we wanted to see how far we could get by replacing webpack with rspack, then by replacing webpack plugins with rspack equivalents and building the bundle locally. With the findings documented, we moved to the next part of the prototype, running rspack and webpack side by side in the CI build pipeline. After that, it was a wider test by the QA team to check for regressions, and more engineers trying it out locally and in Docker.

When we were certain that Rspack could build the bundle, that there were no test regressions, and that we had benchmark data showing an improvement, we moved to implementation.