Look at the tools under a modern frontend and you will notice something. Almost none of them are written in JavaScript anymore. Vite's new bundler, Rolldown, is Rust. Its parser and linter, Oxc, is Rust. Next.js ships Turbopack, Rust. Biome replaced ESLint and Prettier, Rust. Tailwind v4's engine, Rust. Astro 7 just moved its compiler to Rust too.
I run the Vite stack, so this happened right under my feet. It got me asking a bigger question. My backend is Go. If the whole industry is rewriting its tools in Rust, am I on the wrong side of history? Should I be rewriting my Go API in Rust too?
I dug into it. The short answer is no, and the reason why is more interesting than the trend itself.
First, a correction: it is not all Rust
The headline everyone repeats is "JavaScript is being rewritten in Rust." That is half true, and the missing half is the important part.
Rust did win the bundlers and linters: SWC, Turbopack, Rolldown, Oxc, Biome, Rspack. But esbuild, the tool that started this whole speed race, is written in Go. And the new TypeScript compiler, the one that made tsc roughly 10x faster, was written in Go too, by Microsoft, on purpose, after they looked at Rust and chose not to use it. Bun, the runtime everyone lumps into the Rust story, is actually written in Zig.
So the real trend is not "everything is moving to Rust." It is "everything is moving off interpreted JavaScript and onto a fast compiled language." Rust is the most popular choice, but Go and Zig are right there winning major pieces. Hold onto that, because it answers my whole question.
Why they did it
These tools were rewritten for one specific reason: they do heavy, CPU-bound batch work. Bundling means parsing and transforming millions of lines of code in one shot. Linting means walking enormous syntax trees. That is exactly the kind of number-crunching that JavaScript, single-threaded and interpreted, is bad at.
Move that work to a compiled language with real threads and you get 10x to 30x speedups. Rolldown is reportedly 10 to 30 times faster than the JavaScript-based Rollup it replaces. That is not a rounding error, that is a different category of tool. The rewrites happened because the old tools hit a ceiling that was baked into the language they were written in.
The impact, the good and the messy
The good part is obvious and real. I got a big build speedup on my own site and did nothing to earn it. The tooling got faster underneath me. That is the dream, free performance from other people's work.
The messy parts are quieter, and I hit one personally. Native tools ship as native binaries, one per platform, and that leaks. During my Vite migration my lockfile silently dropped the Linux musl binary because it was generated on my Mac, and my Docker build died with a module-not-found error that had nothing to do with my code. Native speed comes with native distribution problems, and most guides do not warn you.
There is also consolidation. Vite, Rolldown, and Oxc all live under one company, VoidZero, which Cloudflare recently acquired. The tools most of the frontend now depends on are increasingly owned in one place. Faster tools, fewer hands on the wheel. Worth watching.
So should I rewrite my Go backend in Rust?
Here is where that earlier correction pays off. The trend is interpreted moving to compiled. Go is already compiled. My backend is already on the winning side of the line these rewrites are about. The JavaScript tools were escaping a ceiling that Go does not have.
And the deeper point: my backend is not doing the work that justified those rewrites. Bundlers are CPU-bound batch crunchers. My API is the opposite. It waits on DynamoDB, waits on S3, serializes some JSON, and sends a response. It is I/O-bound. Almost all of its time is spent waiting on the network, not burning CPU. Rewriting it in Rust would make the CPU parts faster, and the CPU parts are already a rounding error next to the waiting. I would take on Rust's borrow checker and slower iteration speed to optimize the part that was never slow.
The clincher, for me, is that even the experts picked Go for exactly this kind of reasoning. Microsoft had every resource to write the TypeScript compiler in Rust and chose Go, because it fit the problem and the team without Rust's complexity tax. esbuild, the tool that kicked off the whole race, is Go. If Go is good enough to power the fastest TypeScript compiler ever shipped, it is good enough for my little API. "Native" was never a synonym for "Rust." Go is one of the native winners.
The different perspective, honestly
Let me argue the other side, because "I don't need it" can be lazy, and I want to earn the conclusion.
There is a real version of this where I do reach for Rust. Not a rewrite, a component. If my site ever grew a genuinely CPU-bound hot path, heavy image processing at real volume, some compute-intensive endpoint, a piece where garbage-collection pauses actually hurt, that specific piece would be a fair candidate for Rust, or for compiling to WebAssembly and running it in the browser. My photo gallery does image and thumbnail work, and that is the one corner of my project where Rust could genuinely earn its seat. Today it is low volume and Go handles it fine. If that changed, I would rewrite that one module, not the whole backend.
And there is the honest career answer. Learning Rust is worth doing regardless of whether my site needs it, because it teaches you memory and ownership in a way that makes you better in every other language. That is a reason to learn Rust. It is not a reason to rewrite a working Go API.
The actual takeaway
The lesson of the great JavaScript rewrite is not "use Rust." It is "match the language to the shape of the work." JavaScript tooling moved to compiled languages because it was doing compiled-language work in an interpreted language. That mismatch is what got fixed. My Go backend does not have that mismatch. It is a compiled language doing I/O-bound web work, which is exactly what Go is best at.
So I am not rewriting anything. Not because I am ignoring the trend, but because I actually read it. The trend already agrees with me: it just picked Go for the jobs that looked like mine.