Introduction#

Why Rspack?#

Rspack was initially created to solve performance problems encountered at ByteDance, a tech company that maintains many large monolithic app projects with complex bundling requirements. Production build times had grown to ten minutes or even half an hour in some cases, and cold start times could exceed several minutes. After experimenting with many bundlers and optimization ideas, a common set of requirements emerged:

• Dev mode startup performance. npm run dev is a command that developers may invoke many times per hour. Engineering productivity suffers if startup time exceeds 10-15 seconds.
• Fast builds. npm run build is used in CI/CD pipelines and directly impacts merging productivity and application delivery time. Large applications may spend 20-30 minutes running these pipelines, and bundling time is often a major contributor.
• Flexible configuration. From experimenting with various popular bundlers, we found that one-size-fits all configurations encountered many problems when trying to accommodate real world projects. A major advantage of webpack is its flexibility and ease of accommodating customized requirements for each project. This in turn may pose steep migration costs for legacy projects that try to migrate away from Webpack.
• Production optimization capabilities. All of the existing bundling solutions also had various limitations when optimizing for a production environment, such as insufficiently fine-grained package splitting, etc. Rspack was an opportunity to rethink these optimizations from the ground up, leveraging Rust-specific features such as multithreading.

Current status of Rspack#

Rspack has been under continuous development since April 2022, and was launched as open source in March 2023. Although the project is still in its early stages and lacks many webpack functionalities, based on the Pareto principle, we believe the current features can meet the needs of most businesses. Some ByteDance internal projects have already achieved a 5-10 times improvement moving from Webpack to Rspack, and there's still room for future optimizations.

Rspack is compatible with webpack's configuration schema and loader architecture. You can seamlessly use familiar loaders such as babel-loader, less-loader, sass-loader, vue-loader, etc.

Currently, Rspack's cache support is relatively simple, only supporting memory-level caching. In the future, we will build stronger cache capabilities, including migratable persistent caching, which will bring greater imagination space, such as reusing Rspack's cloud cache on different machines in monorepos, to improve the cache hit rate of large projects.

The future of Rspack#

Although Rspack already meets the needs of many projects, there is still a big gap to reach the full capabilities of webpack. Prioritization will be based on community feedback, so please tell us about your requirements!

Collaboration with community partners#

We are very willing to provide support to framework teams and toolchains within the community to unleash the true performance advantages of Rspack. If your framework or toolchain has a demand for high-performance build engines, let us know!

Enhancing plugin capabilities#

Rspack already implements the basic Loader interface and a small number of webpack plugin APIs. Although our goal is not to achieve 100% compatibility for plugin APIs, we will try our best to implement the mainstream requirements based on community feedback. At the same time, we are also exploring higher-performance plugin communication solutions to reduce the cost of plugin communication, thereby ensuring more plugin APIs can be implemented.

Continuously improving performance#

Performance is the core selling point and focus of Rspack development. In the future we'll explore higher-performance concurrent/multi-core-friendly algorithms, higher-performance caching solutions, higher-performance plugin communication solutions, etc.

Expanding the test suite#

Today Rspack is primarily tested using a subset of webpack's test cases. In the future, we'll cover more of these tests, while also expanding the test suite and including community projects to ensure compatibility across Rspack releases.

Compared with webpack#

Webpack is perhaps the most mature modern bundler, with an active ecosystem, flexible configuration, and rich features.

• Rust language efficiency: Webpack's competitors frequently challenge it based on performance, especially for larger inputs. Rspack approaches this using the Rust platform, which was specifically designed to prioritize performance, topping benchmarks for both speed and memory management. Rust also provides many compiler safeguards to avoid common pitfalls of other native languages such as C++.

• Highly parallelized architecture: Webpack is limited by JavaScript's weak support for multithreading. By contrast, Rspack's native code takes full advantage of modern multi-core CPUs.

• Built-in implementations of essential bundling features: webpack's hook system famously enables a vast landscape of loaders and plugins contributed by the community. Unfortunately these third-party packages can frequently lead to performance bottlenecks, perhaps because the authors did not have deep knowledge of webpack internals, or simply because the hook system by nature limits interaction of algorithms. Rspack provides built-in implementations of key bundling features to improve performance.

• Optimized Hot Module Replacement (HMR): No matter how large your project is, ensuring a great experience for HMR places even steeper demands for build times than ordinary bundling. Rspack incorporates a specialized incremental compilation strategy to address this requirement.

Compared with Vite#

Vite offers a great developer experience, but its reliance on Rollup for production builds faces similar performance costs as other JavaScript-based algorithms. The same tradeoffs of webpack versus Rollup also apply, for example flexibility of the optimization.splitChunks feature.

Compared with esbuild#

esbuild achieves very good performance by implementing nearly all operations in Golang except for some JavaScript plugins. However, esbuild's feature set is not as complete as webpack, for example with respect to JavaScript Hot Module Replacement (HMR) and incremental compilation, and also the optimization.splitChunks feature.

Compared with Turbopack#

Turbopack is implemented in Rust like Rspack, but Turbopack started over with a redesigned architecture and configuration. This brings some benefits, but presents a steeper migration cost for projects that rely on webpack and its extensive ecosystem.

Compared with rollup#

Rspack and rollup are both bundling tools, but they focus on different areas. Rollup is more suitable for bundling libraries, while Rspack is more suitable for bundling applications. Therefore, Rspack has optimized many features for bundling applications, such as HMR and Bundle splitting. Rollup produces ESM outputs that are more friendly to libraries than Rspack. There are also many tools in the community that encapsulate rollup to some extent and provide more friendly support for bundling applications, such as vite and wmr. Currently, Rspack has better production build performance than rollup.

Try it#

We've prepared two online demos to see how fast the Rspack is:

• Rspack with React
• Rspack with Modern.js