Rspack: A fast Rust-based web bundler | Hacker News Reader

Rspack: A fast Rust-based web bundler

github.com

From their intro [0]: We created Rspack to solve various performance problems we encountered while maintaining building tools at ByteDance. There were no tools in the market that could solve these problems well. We have a large number of monolithic applications within the company, all of which have very complex webpack configurations.

This makes rspack looks like a competitor to Turbopack which is marketed as webpack's successor.

[0] https://www.rspack.dev/guide/introduction.html

ByteDance seems to be putting out a lot of open source Rust libraries (e.g. Monoio). How widely used is Rust within the company?

Monoio:

> Rust async runtime based on io-uring.

Awhhh heck yeah!

It's been a bit disheartening that neither Node.js/libuv[1] nor Deno[2] have adopted io_uring. Nice to see some signs of adoption. Bun too.

Side note, I was a bit confused about you mentioning ByteDance, but if I go to the web-infra-dev[3] github page, the description is We are from ByteDance, our goal is to build an open technical ecosystem to promote the development of frontend technology, so now it make sense. Just sharing in case anyone else is confused.

[1] https://github.com/libuv/libuv/issues/1947

[2] https://github.com/denoland/deno/issues/16232

[3] https://github.com/web-infra-dev

I wonder how this compares (performance and feature-wise) to esbuild (https://github.com/evanw/esbuild), which is also a bundler written in a compiled language (Go)? esbuild claims to be 10-100x faster than JS-based builders, while Rspack doesn't provide any concrete numbers (at least I didn't find any)...

> We have already used Rspack in internal projects and achieved a 5-10 times improvement in compilation performance.

Per their intro[0] page, I would recommend to read the entire intro page, it give some thought and brief comparison between webpack, vite, esbuild and turbopack.

[0] https://www.rspack.dev/guide/introduction.html#current-statu...

This is a big difference though

> 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, etc. Our long-term goal is to fully support most popular loaders including more complex cases such as vue-loader.

This depends of how many js hooks are used and how efficient they are. Large builds with many plugins / loaders have a parallelism bottleneck with native moving data back to JS.

The slower end, I’ve seen at least 5x improvement. Upper end, I’ve seen 30x. for a optimized prod build.

The project is quite new & fine tuning as it matures will most likely achieve further speed gains. The big benefit is you have a webpack level api & existing ecosystem support. Many current tools offer you speed in trade for api surface.

Smaller api & JS hooks, more speed. I’m not sure what the diff between them is. But a 20k cold dev build takes about 2 seconds. No incremental or lazy compilation is built in, in the initial release.

Rspack offers enormous real world build gains against webpack, while preserving its ecosystem which is a very welcome balance in speed vs power. As a big user & writer of custom plugins or complex builds, I’m not necessarily looking for the absolute fastest build. If a 40 second build takes 2, and esbuild takes 1 - its a negligible difference that I’d be happy to accept for a robust api.

At 50k modules, if a prod build taking ~15 seconds seems plenty fast - those represent some of the largest codebases.

If I were the author, I would consider renaming this, as "spack" (from the etymology "spastic" -> "spacker") is an offensive term for someone with cerebral palsy, in British English.

I feel like this deserves a shot at the 2nd chance queue even though it's a corporate project. Slipping under the radar on HN!

Reply on news.ycombinator.com