If you've spun up a React, Next.js, Vue, or Vite project anytime recently, you've probably used Rust today.
You just didn't know it.
You wrote JavaScript or TypeScript. The browser got JavaScript. Almost everything in between—the compiler, the bundler, the linter, the formatter, the CSS optimizer, sometimes even the runtime—was likely written in Rust.
This isn't a hot take about the future. It's already the default stack for a lot of us. We just keep calling it "the JavaScript ecosystem" because that's still the language we ship.
The shift nobody notices
For years, JavaScript developers fixed JavaScript problems by writing more JavaScript.
Need a compiler? Babel.
Need a bundler? Webpack or Rollup.
Need linting? ESLint.
Need formatting? Prettier.
Every layer was JavaScript. Every layer got slower as repos grew. The ecosystem kept adding packages instead of questioning whether JavaScript was the right tool for that job.
Then the interesting thing happened.
People stopped trying to make the old tools faster. They replaced the tools.
Not with another framework. With Rust.
You're still writing React. Calm down.
I keep seeing the same panic take: "Is Rust going to replace JavaScript?"
No.
You're not rewriting your dashboard in Rust next quarter. You're still shipping React, Vue, Next.js, TypeScript, Node. That layer is fine. That layer is the product.
The change is everything under your code.
Your Code │ ▼ Compiler │ Bundler │ Linter │ Formatter │ Optimizer │ Browser
Five years ago, almost every box above was JavaScript. Today, most of them aren't.
Why build tools matter more than frameworks
Hit save in a real app and your editor isn't "refreshing." It's chewing through a lot of boring, expensive work:
- reading thousands of files
- parsing JS and TS
- building ASTs
- resolving imports
- tree-shaking
- bundling
- optimizing assets
- generating source maps
None of that is clever. It's mechanical. CPU-heavy. Exactly the kind of work where language performance stops being academic and starts deciding whether you wait 90 seconds or 9.
Framework debates are loud. Toolchain speed is quieter—and it quietly owns your day.
Why JavaScript hits a ceiling here
JavaScript is great for apps. It was never designed to be a compiler language.
One thread, eight cores sitting around
Modern machines have 8, 12, 16 cores. A typical JavaScript build process still spends a lot of time on one main thread. Parse a thousand files one after another when the silicon could be doing them in parallel—and you feel it.
Rust makes that kind of parallelism practical for tooling. More cores actually show up for work.
Garbage collection pauses
GC is convenient until you're holding a giant AST made of millions of tiny objects. Small projects shrug. Large monorepos notice. Rust doesn't pause to clean house the same way—memory is released when you're done with it.
No warm-up tax
V8 is incredible. It still has to parse, optimize, and warm up when a JS tool starts. Rust tools arrive as native binaries. They start cold and still feel fast.
Why Rust and not "just use C++"?
We've had C++ forever. Performance wasn't the missing piece. Safety was.
Memory corruption. Segfaults. Use-after-free. Data races. The kinds of bugs that make infrastructure teams lose weekends.
Rust's borrow checker catches whole categories of those at compile time. Near C/C++ speed, with fewer footguns. For tools millions of developers run every day, that trade matters.
You don't leave npm to get this
This is the part that made the migration inevitable.
You don't rewrite your app. You don't leave Node. Packages built with napi-rs show up as normal npm imports:
import compiler from "some-package";
Looks ordinary. Feels ordinary. Runs Rust underneath.
That bridge is why adoption didn't need a culture war. It just needed a faster next build.
Around 2020, two things lined up: Rust was mature enough for production tooling, and native Node addons got easy enough that you didn't need a science project to ship them. Builds had also gotten slow enough to hurt. Slow is a fantastic motivator.
The tools quietly taking over
SWC
Babel taught a generation how to transform JavaScript. SWC does the same job—in Rust. Next.js made it the default years ago because large projects stop feeling punished for existing.
If you're on modern Next, your code probably already went through SWC today.
Same job. Different language. The difference is not subtle.
Turbopack
Webpack ran the frontend for more than a decade. Turbopack is Vercel's Rust bet for the next one. In recent Next.js releases it's become the default path for a reason developers actually care about: Fast Refresh that feels instant.
Save. See it. Stay in flow. That loop is the product.
Rspack
ByteDance didn't wait for a perfect open-source timeline. They built Rspack—and the clever part isn't only speed. It's Webpack compatibility. Teams can move without rewriting years of config archaeology.
That is a product decision dressed as a technical one. And it works. TikTok, Discord, Microsoft, Amazon—real production, not toy repos.
Oxlint and Biome
Everyone knows ESLint. Everyone has also watched it crawl a giant codebase like it's thinking about each line personally.
Oxlint exists because that pain is real. Biome goes further: one binary instead of ESLint + Prettier + a plugin graveyard. Format, lint, fewer configs, less dependency theater.
The ecosystem is finally learning that "more packages" is not a personality.
Rolldown
Evan You—Vue, Vite—built Rolldown as a Rust-era Rollup. Vite's recent major line puts Rolldown in the default seat. Given how many greenfield apps start with Vite, that one switch moves a huge chunk of the web.
Lightning CSS
Even CSS tooling joined the migration. Parse, transform, prefix, minify—faster, under the hood, often without you noticing.
Deno
Rust showed up in the runtime conversation too. Deno's core is Rust. Early npm friction was the story. Deno 2 closed most of that gap. Whether you adopt it or not, the pattern is the same: systems language underneath, JavaScript on top.
Companies aren't doing this for vibes
Benchmarks are fun. Production calendars are not.
When a team cuts builds from minutes to seconds, they don't just "save time." They stop losing focus a hundred times a week. Interrupted thought is expensive. Tooling that respects attention is a business advantage, not a flex.
The biggest names aren't arguing about Rust on Twitter. They're shipping it in the tools their engineers hit every hour.
The quieter story: shared foundations
What surprised me most isn't any single tool. It's that the Rust tooling world is starting to share guts—parsers, engines, cores—instead of every project reinventing the same expensive wheels.
One foundation. Many tools. Less duplicated work. More consistency. That is how an ecosystem matures when it stops pretending every problem needs a new npm package.
Then Cloudflare bought a piece of the future
In 2026, Cloudflare acquired VoidZero—the org behind a lot of modern JS tooling work around Rolldown, Ox, and friends.
They weren't buying a logo. They were buying leverage over the infrastructure developers touch daily. Infrastructure companies understand something app developers sometimes miss: whoever owns the tools shapes the defaults. Defaults shape the web.
But it's not only Rust
This is where the discourse gets sloppy.
esbuild (Go)
The project that really kicked off "fast tooling" for a lot of us wasn't Rust. It was esbuild, written in Go. Still absurdly fast. Its success proved the real leap: stop running heavy tooling as JavaScript.
TypeScript's compiler (also Go)
One of the biggest engineering stories recently: Microsoft's TypeScript rewrite aiming at order-of-magnitude speedups—in Go, not Rust.
Anders Hejlsberg's explanation is the adult one. TypeScript's architecture leans on shared mutable structures. Porting that straight into Rust's ownership model would mean redesigning the brain, not just the language. Go fit the existing shape better.
That's an engineering trade-off. Not a scoreboard.
Bun (Zig… and then Rust)
Bun was the counterexample for a while—blazing performance in Zig. Lately even Bun has been pulling Rust into parts of the stack for memory safety. The "counterexample" joining the trend is its own kind of signal.
So… is Rust winning?
Yes. Just not the way headlines sell it.
Rust isn't replacing JavaScript.
Rust is replacing JavaScript tooling.
You're still writing this:
function App() { return <Dashboard />; }
Nothing changes in how you think about UI. Behind the scenes, the compiler, bundler, formatter, linter, CSS optimizer—maybe the runtime—are increasingly Rust. You get the speed without changing how you build products.
That's why this stuck. Low ceremony. High payoff.
The new philosophy
For a decade we asked: how do we make JavaScript tools faster?
The better question turned out to be: keep JavaScript for the application, and move the expensive work into a compiled systems language.
Rust. Go. Zig. Different bets, same idea.
Not replacing JavaScript.
Supporting it.
Strengthening it.
Accelerating it.
Should you learn Rust?
If your only goal is shipping React apps? Probably not required. Modern tooling already hands you the benefits for free.
If you care about compilers, infra, language tools, databases, systems work, high-performance backends—then yes, Rust starts looking less like a trend and more like the language behind the tools you already depend on.
Final thoughts
This isn't a language war. It's an infrastructure upgrade.
Quiet. Gradual. One binary at a time.
Your components are still JavaScript. Your APIs are still TypeScript. Deploy still feels familiar. The engine room changed anyway.
Next time a project builds in seconds instead of minutes, remember: it probably wasn't JavaScript that made it faster.
It was the language underneath it.
If you like posts that go under the hood, you might also enjoy Why Astro Wins the Race Over Other Frontend Frameworks—another place where "what's underneath" beats the loudest framework debate.