Why Your Frontend Tools Are All Written in Rust Now

Your npm run dev is quietly running Rust. Not a little Rust — a lot of it. Turbopack bundles your code, SWC strips your TypeScript, oxc validates your imports, and Biome enforces your style guide. The JavaScript toolchain has rewritten itself from the ground up in a systems language, and it's not going back.

The Speed Problem That Forced a Rewrite

JavaScript-based tools dominated the 2010s: Webpack, Babel, ESLint, Prettier. They worked, and the ecosystem around them was massive. But they also shared a structural problem: Node.js is single-threaded and interpreted.

On a large application with hundreds of modules, a cold Webpack build could take 60–90 seconds. Hot reload felt sluggish. Full lint runs before a commit? Painful enough that developers disabled them. The tools weren't buggy — they hit the ceiling of what the runtime could deliver.

The ecosystem needed true parallelism, native execution speed, and no garbage collection pauses during a hot-reload cycle.

The Rust Wave

One by one, core tools rewrote in Rust:

• SWC — TypeScript and JSX transpiler, used by Next.js. Replaces Babel. 20–70x faster in benchmarks.
• Turbopack — Next.js's incremental bundler. Benchmarked at 10x faster HMR than its webpack-based predecessor.
• oxc — A suite: parser, linter, transformer, and resolver. The parser is reported as ~3x faster than Babel's.
• Rolldown — The upcoming Vite bundler, aiming for full Rollup API compatibility with native speed.
• Biome — Linter and formatter in one binary. Drop-in replacement for ESLint + Prettier in most projects, reported ~25–35x faster than Prettier.

Rust's value proposition here is concrete: zero-cost abstractions let you write high-level code that compiles to machine instructions with no runtime overhead. Real OS threads mean the parser and bundler can saturate all your CPU cores. No garbage collector means no unpredictable pause during a tight HMR loop.

Old vs New: What Changes at the Config Level

{
  "extends": ["eslint:recommended"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error",
    "no-unused-vars": "warn"
  }
}

Real Benchmarks Worth Knowing

Numbers should always come with caveats — benchmarks depend on project size, caching, and hardware. That said, the reported gains are hard to ignore:

• Biome: ~25–35x faster formatting than Prettier on large files (Biome team benchmarks)
• Turbopack: ~700ms cold start vs ~7s for webpack on a large Next.js app (Vercel benchmarks)
• SWC: typical 20x improvement over Babel on transpilation

These aren't marginal wins. They change what's possible in a CI pipeline or a tight dev loop.

What This Means for You

Here's the key point: you don't need to write Rust. These tools are distributed as pre-compiled binaries and npm packages. You install Biome the same way you installed ESLint:

npm install --save-dev @biomejs/biome
npx @biomejs/biome init

Migration from existing tools is generally smooth. Biome's docs walk through ESLint and Prettier migrations. Turbopack is already the default in next dev. SWC is on by default in Next.js and available in Vite.

The ecosystem shifted, but you are not forced to follow the internals — just the config.

The Takeaway

The frontend toolchain's Rust rewrite is not a trend or a rewrite for its own sake — it's the ecosystem catching up to the scale of modern applications. Faster builds, faster linting, and faster deploys are now table stakes. The tools are ready; switching is low-risk and the gains are immediate.