Software Engineering · Chapter 15 of 31
Build tooling after the Rust migration
One bundler for dev and prod, three vendor camps, a runtime that changed hands — and why almost every number in this chapter is published by someone who benefits from it.
One sentence carries this whole chapter: the JavaScript toolchain finished migrating to Rust between 2024 and 2026, consolidated into three vendor camps, and demoted the tool everyone used to name from something you choose into a component inside other things.
The three camps
| Camp | Stack | Position |
|---|---|---|
| The Vite ecosystem | Vite, Rolldown, Oxc | The default for everything that is not Next.js. Rolldown replaced both the dev transformer and the production bundler |
| The Rspack ecosystem | Rspack, Rsbuild, Rslib, Rsdoctor, Rstest | The near-drop-in escape route for large webpack codebases — the migration path, not the greenfield choice |
| Turbopack | Bundled with Next.js | Not a standalone product you adopt; it arrives because you chose the framework |
Vite 8, and the architectural change that matters
Vite 8 shipped on 12 March 2026. The headline is not speed — it is that Rolldown replaced both the transform layer and the production bundler, so development and production now use the same bundler.
That ends a long-standing class of bug that most teams never diagnosed properly: the ‘works in dev, breaks in prod’ failure caused by two different tools with subtly different module resolution, interop handling and tree-shaking. It is a correctness improvement dressed as a performance release.
The React plugin also moved from Babel to Oxc. The costs are honest and small: a Node version floor, and roughly 15 MB more install size for the native binaries.
Published build-time reductions from named customers — all vendor-sourced — include one company going from 46 seconds to 6, and reductions of 57%, 64% and 38% at three others.
Turbopack, and one very testable detail
Turbopack became the default in Next.js 16 (21 October 2025). The vendor's own published figures are unusually credible for this space because they name real applications with before-and-after numbers, which the named companies could contradict:
- Development memory after compiling fifty routes on their own dashboard: roughly 21.5 GB down to 2 GB, and on their documentation site 4,600 MB to 840 MB — achieved through memory eviction backed by an on-disk cache.
- Production builds with the persistent filesystem cache, now the default: 21 seconds to 9.2, 66 to 46, and 30 to 5.5 on three of their own properties.
- The detail to remember, because it is concrete and testable: that cache lives in the build output directory. Continuous integration only benefits if that directory is restored between runs. A team that adopted the new bundler and saw no CI improvement almost always has an un-cached pipeline, and that is a five-minute fix.
Where webpack actually stands
Not dead. Structurally displaced. Both halves of that matter.
It still records more weekly downloads than Next.js does. And in the most recent large ecosystem survey it was still the most-used build tool — ahead of Vite on usage.
But look at the satisfaction split: webpack sits at a net negative of roughly 23 points; Vite at a net positive of about 55. Fourteen percent positive against thirty-seven percent negative, versus fifty-six against one.
High usage plus deeply negative sentiment is exactly what a tool looks like in its last two years before becoming purely a maintenance skill. Learn enough webpack to work in an existing codebase; do not build a career identity on configuring it.
And the related career point: “configure webpack” is no longer a frontend skill. “Reason about what the bundler is caching and when that cache is invalid” is.
The other demotion: the Go-based transformer that powered the last generation records enormous download numbers and is almost never chosen directly any more. It is the transform layer inside other tools — and Vite 8 just removed it from Vite. Its future is library builds and niche tooling, not application builds.
Runtimes
On the alternative-runtime side, the notable structural event is that Bun was acquired by Anthropic in December 2025. It remains open source under the MIT licence and the team continues; it underpins Claude Code, which ships as a single compiled binary. Version 1.4 arrived on 20 August 2026 claiming a rewrite of the runtime from Zig into Rust and Node 26.3 compatibility with over fifteen hundred newly passing tests.
State that rewrite claim as the vendor's claim rather than as fact. A full runtime rewrite between minor versions is an extraordinary assertion and it is not independently corroborated. The practical enterprise pattern reported consistently is a hybrid: install and test with the fast runtime in continuous integration, run Node in production.
Why almost no build benchmark deserves your trust
1. Every number is published by the party that benefits. The Vite figures come from the Vite company, Turbopack's from the framework vendor, Rspack's from its parent company, each compiler's speed claims from its own team.
2. The baseline is usually the vendor's own previous version, not a competitor's current one. ‘Three times faster’ frequently means three times faster than last year's release of the same tool.
3. Cold versus warm cache changes the same tool's result by two to five times, and posts rarely say which they measured.
4. Cross-tool benchmarks measure module-graph traversal, which correlates weakly with real applications dominated by type-checking, CSS pipelines and source maps.
5. The one class of claim that deserves more weight is a named production application with before-and-after numbers — because the named company can contradict it, and would.
That fifth point is the useful, non-cynical version of this. Do not dismiss vendor data; weight it by falsifiability.
Check yourself