The Frontend Toolchain Is Now Written in Rust and Go. What That Means for You

This month two things landed within days of each other. Cloudflare acquired VoidZero, the company behind Vite, Vitest, Rolldown, and OXC. And the React team merged a full Rust port of the React Compiler into the main repository.

Treated as separate headlines, they are just news. Put next to each other, they finish a picture that has been forming for two years. The frontend toolchain, the layer underneath the code you actually write, is no longer written in JavaScript. It is written in Rust and Go.

These get covered as separate upgrades. They are not separate. They are one migration, and it reaches your job whether or not you ever write a line of Rust.

The shift: JavaScript is the app language, native is the critical path

Line up where each piece of tooling lives now. Type checking moved first. TypeScript 7.0, the Go-native port the team called tsgo, hit RC this month, and the tsc you install is a Go binary that checks types about ten times faster. Bundling went the same way. Vite 8 dropped its old esbuild-plus-Rollup split for Rolldown, one Rust bundler, and real apps saw build times fall by ten to thirty times. Next.js made the Rust-based Turbopack its default, production builds included. Linting and parsing run on OXC, the Rust toolchain that took my own lint pass from twelve seconds to under one when I switched to oxlint back when it was still a niche choice. And the React Compiler, the thing that rewrites your components to memoize for you, is Rust as of this month.

Once you put them next to each other the shape is obvious. JavaScript and TypeScript stay as the language you write product logic in. Everything that has to run on every file, on every save, on every CI run, has been pulled out of JavaScript and into a compiled language. The app is JS. The hot path is native.

Why now: the perf ceiling was never in your code

This did not happen because Rust is fashionable. It happened because the toolchain hit a wall that no amount of clever JavaScript could climb past.

The bottleneck was structural. A linter or type checker or bundler does the same kind of work a compiler does: parse millions of lines into an AST, walk that tree many times, hold a lot of state in memory. JavaScript is a poor fit for that specific workload. Single-threaded by default, garbage-collected at unpredictable moments, and paying a startup tax every time Node boots a plugin. When @typescript-eslint ran slowly, the cause was not the linter, it was the TypeScript language service it had to boot to answer type-aware rules.

You cannot optimize your way out of that in the same language. So the teams that owned these tools did the only thing left: they changed languages. Rust gives them real threads, no GC pauses, and no startup cost. Go gives the TypeScript team memory layout control and concurrency while keeping a codebase their existing contributors can read. The ceiling was in the runtime, not the logic, so they swapped the runtime.

The interesting part is that this only became urgent now. Codebases got big enough, monorepos deep enough, and CI bills high enough that the seconds turned into minutes and the minutes turned into money. The monorepo tooling race was the early warning. This is the same pressure reaching the core tools.

What actually changes when the layer beneath you is native

Debugging gets a new boundary. When a build broke before, you could open the bundler's source, set a breakpoint, and read JavaScript you understood. That escape hatch is mostly gone. A stack trace out of Rolldown, or a panic from a Rust plugin, is not something you step through with the tools you already know. It matters less than it sounds, because these tools fail far less often, but when they do the failure is more opaque. You debug at the edges now, against your config and your inputs and the error message, not the internals.

Contributing got harder in the obvious way and easier in a way nobody mentions. Harder because fixing a bug in your linter now means writing Rust, and most frontend engineers don't. The bar to patch your own tools went up. But these new codebases are small, fast, properly structured compilers, and that makes them far better to read than the sprawling JavaScript plugin systems they replaced. If you ever wanted to understand how a bundler really works, the Rust version is the friendlier place to start, not the scarier one.

The part I would actually watch is what happens to plugins. Vite and Rolldown kept the Rollup plugin API, so the JavaScript plugins you already depend on still load. But a JavaScript plugin sitting in the middle of a Rust pipeline is now the slow link by construction, because every file has to cross back into JS to reach it. The teams know this, which is why OXC and Rolldown are building native plugin paths. Within a year, writing a plugin will quietly mean two different things with very different performance, and anything on the hot path will get pulled toward the native one.

What's overhyped, and what isn't

The loudest take is that you need to learn Rust now. You don't. Moving the toolchain to native code works precisely because it stays behind an interface: you install a binary and run a command. The React Compiler being Rust changes nothing about how you write a component, and tsgo being Go changes nothing about how you write types. The "end of TypeScript" headlines are clickbait. TypeScript the language is more central than it has ever been; only the compiler underneath it moved.

The speed numbers are oversold too. Ten times, thirty times, ten times again. Real, but mostly measured on cold builds and full type checks, which is the worst case. Your actual day is warm incremental rebuilds, where the gap is a lot smaller. The improvement is genuine. The headline multiple is not what you feel on an average afternoon.

What does change is your behavior, quietly. When lint finishes in under a second you stop skipping it locally and leaning on CI to catch things. When type checking is close to instant you run it more often and find problems sooner. Fast tools don't just feel nice, they make good habits cheap enough to actually keep, and that compounds in a way no benchmark captures.

The other real change is consolidation. One company now stewards Vite, Vitest, Rolldown, and OXC, a stack pulled down around 130 million times a week. Cloudflare has made a vendor-neutrality pledge and put money behind an independent ecosystem fund, and I take both at face value for now. But a toolchain that used to be a loose federation of independent projects now has a single owner, and that is worth watching. Not because anyone is acting in bad faith, but because the shape of an ecosystem changes when one party holds that much of it.

What stays durable

None of this changes what makes code good. Faster tools make a bad design fail faster; they don't make it right. Knowing why a build is slow, what a bundler is doing under the hood, when to replace a tool instead of tuning it, how to read a type error instead of guessing at it: that knowledge is language-agnostic, and it carries over cleanly whether the thing underneath is written in JavaScript, Rust, or Go.

So the migration is real, and it is mostly good for you. It relocates complexity rather than removing it, out of your build config and into compiled internals you will rarely open, which leaves more of your attention for the part that was always the job: deciding what to build and how to structure it. Faster tools were never going to make that part easier. They just stop standing in front of it.

I write about system design and the senior-to-staff transition every week in Monday BY Gazar on Substack, and I break down architecture and engineering decisions on Gazar Breakpoint on YouTube. If you want this kind of thinking applied live, my next free session is System Design for AI Agents: Senior vs Staff on Tuesday, July 21, 2026, 6:30 PM GMT+1: 45 minutes on the judgment that separates senior from staff when there's an LLM in the stack. My courses and other free lessons are on my Maven profile.