Rust is eating the JavaScript toolchain
March 7, 2026
The quiet revolution
Look at your JavaScript project's dependency tree and count how many tools are written in JavaScript itself. A few years ago the answer was "all of them." Today, the load-bearing parts are increasingly written in Rust.
SWC replaced Babel for most transpilation. Rolldown is replacing both esbuild and Rollup inside Vite. Oxc is building a full suite of parsers, linters, and transformers. Biome replaced ESLint and Prettier for teams that wanted speed over plugin ecosystems. Even package managers are getting the treatment with tools that resolve dependencies in milliseconds.
Why Rust specifically
The pattern isn't accidental. JavaScript tooling hits a ceiling because it processes JavaScript with JavaScript. Parsing, transforming, and bundling thousands of modules is CPU-bound work where native performance wins by 10-100x. Rust's memory safety without garbage collection makes it a natural fit: you get C-level speed with the confidence that your bundler won't segfault.
What we gain and what we lose
The obvious gain is raw speed. Cold starts that took 8 seconds now take 800 milliseconds. But we also lose something: the ability for any JavaScript developer to read and patch their own tools. Contributing to Oxc requires knowing Rust. Writing a Rolldown plugin means understanding a different mental model.
The pragmatic take
Most developers don't patch their bundler. They configure it, run it, and move on. For that workflow, Rust-based tools are strictly better: faster, more reliable, lower memory usage. The JavaScript ecosystem isn't dying, it's doing what mature ecosystems do, delegating the heavy lifting to lower-level languages while keeping the developer-facing APIs in JavaScript.