Rust Powered JavaScript Tooling: oxc, Biome, and the Speed Revolution

Something interesting has been happening in the JavaScript tooling world over the past few years. The tools we use every day to parse, lint, format, compile, and bundle our code are being rewritten in Rust. And the performance differences are not small improvements. We are talking about tools that are 10 to 100 times faster than their JavaScript equivalents.

Why Rust

JavaScript tooling has traditionally been written in JavaScript (or TypeScript). This makes sense from an ecosystem perspective because JavaScript developers can contribute to and extend the tools they use. But JavaScript is not fast for CPU-bound work like parsing, transforming, and analyzing large codebases.

Rust offers near-C performance with memory safety guarantees. It compiles to native code, has no garbage collector pauses, and its ownership model prevents the memory bugs that plague C and C++ tools. Several teams independently concluded that the best way to make JavaScript tooling faster was to rewrite it in Rust.

SWC: The Babel Replacement

SWC (Speedy Web Compiler) was one of the first Rust-based JavaScript tools to gain mainstream adoption. It is a JavaScript/TypeScript compiler that replaces Babel for transpilation. Next.js adopted SWC as its default compiler in 2021, which brought it into millions of projects overnight.

The performance difference over Babel is roughly 20x for single-threaded compilation and up to 70x when using multiple cores. For a large Next.js project, this can cut build times from minutes to seconds.

SWC also powers the minification step in many build tools, replacing Terser (another JavaScript-based tool) with comparable output quality at much higher speed.

Turbopack: The Webpack Successor

Turbopack is Vercel's Rust-based bundler, designed as the successor to Webpack. It is integrated into Next.js as an opt-in feature for development builds.

The key innovation in Turbopack is incremental computation. Instead of rebuilding the entire bundle when a file changes, Turbopack tracks dependencies at a granular level and only recomputes what is affected by the change. This makes hot module replacement nearly instantaneous even in large applications.

Turbopack is still evolving and does not yet support all of Webpack's features (particularly the vast plugin ecosystem). But for the development use case where it is available, the speed improvement is substantial.

oxc: The All-in-One Toolchain

oxc (Oxidation Compiler) is an ambitious project that aims to build a complete JavaScript toolchain in Rust: parser, linter, formatter, transformer, resolver, and minifier. Each component is designed to share the same AST (Abstract Syntax Tree), which means parsing happens once and all tools operate on the same representation.

# Using oxlint (the linter)
npx oxlint@latest

The oxlint linter is already usable and is 50 to 100 times faster than ESLint. For a project with 1000 files, oxlint finishes in under a second where ESLint takes 30 to 60 seconds. The rule coverage is growing but does not yet match ESLint's extensive plugin ecosystem.

The parser (oxc-parser) is the fastest JavaScript parser available, outperforming both SWC's parser and the popular Acorn parser by significant margins.

Biome: The Formatter and Linter

I wrote about Biome back in late 2023, and it has continued to improve. Biome combines formatting (replacing Prettier) and linting (replacing ESLint) into a single Rust binary. Running biome check does both in one pass.

The speed advantage over running ESLint and Prettier separately is dramatic. On a medium-sized project, Biome runs in about 200 milliseconds where ESLint plus Prettier takes 4 to 6 seconds. In CI pipelines where these checks run on every commit, that time difference adds up.

Biome's rule set has grown to cover most of the commonly used ESLint rules, including many from popular plugins like eslint-plugin-react and eslint-plugin-import. The formatting output is intentionally compatible with Prettier in most cases, so migration is usually straightforward.

Rolldown: The Rollup Rewrite

Rolldown is a Rust-based port of Rollup, created by the Vite team. Since Vite uses Rollup for production builds, replacing it with a Rust version would unify the development (esbuild) and production (Rollup) bundlers into a single fast tool.

Rolldown aims for API compatibility with Rollup, meaning existing Rollup plugins should work with minimal changes. The project is still in active development, but the early benchmarks show 10 to 20x speed improvements over Rollup for the bundling step.

When Rolldown is stable, Vite plans to use it as the default bundler for both development and production. This would make Vite's production builds significantly faster and eliminate the subtle differences between the dev and prod build pipelines.

The Tradeoff

Speed comes at a cost: extensibility. ESLint's power comes from its plugin ecosystem. Thousands of custom rules written by the community cover everything from accessibility to security to framework-specific patterns. Those plugins are written in JavaScript and cannot run inside a Rust tool.

The Rust tools handle this in different ways. Biome is building its own rule set natively. oxc is doing the same. Some tools support JavaScript plugin APIs that call out to JS code, but this adds overhead and complexity.

For teams that rely heavily on custom ESLint rules, migration to Rust tools is not yet practical. For teams using the standard rule sets, the migration path is clear and the speed benefits are compelling.

Where This Is Going

I think we are in the middle of a generational shift in JavaScript tooling. The tools built in the 2015 to 2020 era (Webpack, Babel, ESLint, Prettier) were excellent for their time, but they are hitting performance ceilings that JavaScript cannot overcome. The Rust rewrites are not incremental improvements. They are fundamental performance jumps that change how quickly you can iterate.

In a year or two, I expect most JavaScript projects will be using Rust-based tools for at least parsing, formatting, and linting. The JavaScript originals will still exist and still be used, especially where plugin ecosystems are critical. But the direction is clear: the performance-critical parts of the JavaScript toolchain are moving to Rust, and the developer experience is better for it.