Rust is Quietly Eating JavaScript's Backend

You ran a build, React went in, a browser bundle came out. And the tool that did the actual work is not written in JavaScript, it is written in Rust. Your transpiler, SWC, that is Rust, your bundler, TurboPack, also Rust. The JavaScript is just the input. So here is the real shift. Rust is not replacing the code you write. It is replacing the tools that build, check, and run it. Take your linter. OxLint does ESLint's job 50 to 100 times faster. A full minute of checking becomes milliseconds. Your formatter and linter together? Biome is one small binary that replaces ESLint, prettier, and 100 plus packages. Your bundler. Rolldown just hit 1.0 and Vite made it the default. Retiring rollup. The old JavaScript engine under it. Your framework. Next. JS16 now ships TurboPack as the default for development and production. Webpack is on the way out. And the people behind this are not a mystery. Evan Yu, who made Vue and Vite, the creators of SWC and Ox, real names in the open. This is not a hobby anymore either. In June, Cloudflare bought the company building most of these Rust tools. One honest catch up front, it is not only Rust. Go is in this fight too, and it just won a big round. We will get there. You could go your whole career without writing a line of Rust yourself. You are already running it. Every build. Every save. Every deploy. So let me show you what is actually happening underneath your JavaScript. Why it is happening. And where the honest line really is. Start with what these tools actually do. Because the why falls out of it. A bundler reads your code. Parses it into a tree of millions of tiny nodes. Walks that tree. Rewrites it. And stitches everything back into one file. None of it is clever. It is just a mountain of mechanical, repetitive work, repeated on every single save. And that is exactly the kind of job where the language you built the tool in matters more than anything else. Here is the problem with building those tools in JavaScript itself. JavaScript runs on one thread. One. Your laptop has eight cores. Maybe 16. And a JavaScript tool can genuinely use one of them at a time. But parsing 100 files is 100 independent jobs that could run at once. Rust just hands each core a stack of files and lets them all go. That single difference is most of the speed you are seeing. Then there is memory. JavaScript manages it for you with a garbage collector. And every so often it pauses everything to clean up. On a small app you barely feel it. On a giant syntax tree with millions of objects churning, those pauses add up into real, visible lag. Rust has no garbage collector. It frees memory the instant it is done on a schedule you can predict. No pauses. No stalls. No surprises mid-build. And JavaScript is interpreted. It gets compiled on the fly while it runs by a very smart engine that still has to guess and warm up first. Rust is compiled ahead of time, straight to machine code, before it ever runs. For a tool you launch, run flat out, and close. That warm up you pay in JavaScript is pure waste. Rust simply skips it. So why Rust specifically, and not just any fast language? Because Rust gives you the raw speed without the usual price. In older systems languages, going this low level means you can corrupt memory and crash the whole thing. Rust has a borrow checker that catches those mistakes when you compile, before anyone runs the code. You get C-level speed with a seatbelt. For a tool that millions of developers depend on daily, that seatbelt is the whole point. And you do not have to leave Node to get any of it. There is a bridge called nappy-rs that lets you write a piece in Rust, compile it, and call it from JavaScript like any normal package. You install it with npm, you import it like anything else. The Rust is invisible. That bridge is how swc, rolldown, and half of this list actually reach you, dressed up as ordinary npm packages you already have. One more question worth answering. Why now and not 5 years ago? Two things had to line up. Rust itself had to mature. And that bridge to Node had to get good enough that shipping a Rust tool felt like shipping any npm package. Around 2020, both happened. And the pain finally got bad enough. JavaScript builds had grown so slow that teams were losing real minutes on every save. Slow is a fantastic motivator. Let me walk the actual lineup, because it is bigger than most people realize. Start with swc, the speedy web compiler. It is the Rust tool that turns your modern JavaScript and TypeScript into code browsers understand, the job Babel used to own. It is around 20 times faster than Babel on one core, and much more across many. Next.js switched to it as the default years ago. If you ship a React app, swc has probably already touched your code today. swc was made by a developer who goes by kdy1. And after he built it, Vercel hired him to build the next thing, TurboPack. TurboPack is the bundler meant to replace Webpack, and as of Next.js 16, it is the default for both development and production. The number people feel is fast refresh, the gap between saving a file and seeing the change. TurboPack does that up to 10 times faster than Webpack, with production builds 2-5 times faster. And Vercel is not the only giant in this. ByteDance, the company behind TikTok, built its own Rust bundler called rspack. The clever move was making it a near drop-in for Webpack, so teams can switch without rewriting their config. Real migrations report builds roughly 9 times faster, using about a third of the memory. It runs in production at TikTok and Discord, and inside tools at Microsoft and Amazon. This is not fringe tooling, now the one that turns heads. Ox, the Oxidation compiler, is a whole family of Rust tools, and its linter, OxLint, went stable in 2025. ESLint, checking a large codebase, can take a full minute or more. OxLint does the same checks in the time it takes to blink, 50-100 times faster. And it gets faster the more cores you throw at it. Shopify, Airbnb, and Mercedes already run it. The old linter cannot keep up with that. Right next to it sits Biome, which does linting and formatting in one Rust binary. The jobs ESLint and Prettier split between them, plus the 100-odd packages they drag along. Biome is a single download. Its 2.0 release pulled off something the JavaScript tools struggled with, type-aware linting without booting the entire TypeScript compiler. It runs 10-25 times faster than the ESLint and Prettier combo, and it is genuinely pleasant to use. Then the newest arrival, and maybe the most important one. Rolldown is a Rust bundler built by Evan Yu, the person who created Vue and Vite. It hit 1.0 in May, and Vite 8 now uses it by default. That matters, because Vite is what a huge share of new projects start with today. Rolldown is 10-30 times faster than Rollup, the JavaScript bundler it replaces, and the gap only widens as your project grows. It is not only the build tools, either. The runtime is in play, too. Deno is an alternative to Node, and its core is written in Rust. For a long time, the knock on it was that it could not run your existing NPM packages. That is over. Deno 2 runs the vast majority of the NPM ecosystem, reads your normal package files, and behaves like Node where it counts, on a Rust foundation instead of Node C++ 1. Even your CSS is not safe from this. Lightning CSS, written in Rust, parses, transforms, and minifies style sheets far faster than the JavaScript tools that used to do it. Parcel uses it. Vite reaches for it. It is the same story one layer down. A boring, repetitive job handed off to a compiled language, while the rest of us argued about frameworks. And these are not benchmark numbers on a toy project. A company called Muse cut its build startup from 3 minutes down to 10 seconds by switching bundlers. Ramp shaved more than half off its build time. When a build drops from 3 minutes to 10 seconds, that is not a nice to have. That is dozens of times a day you get your focus back instead of handing it to a spinner. And look at who is behind these tools, because it reads like a who's who. Vercel builds SWC and TurboPack. ByteDance built RSpec. VoidZero, now CloudFlare, builds Rolldown and Aux. The users read the same way. Shopify, Airbnb, Discord, Mercedes, Microsoft. When the biggest names in web development all land on the same direction at once, it usually means something real is happening. And notice the pattern forming, because this is the part that surprised me. These are not 10 unrelated projects. Aux and Rolldown share the exact same Rust parser. Rolldown feeds V8. The plan is one shared Rust core, one parser, one set of internals with a bundler, a linter, a formatter, and a test runner all built on top. Instead of 100 loosely glued JavaScript tools, one fast engine underneath all of them. Is anyone actually adopting this? Or is it just hype? The State of JS survey is the closest thing the community has to a headcount. And in one year, Rolldown went from 1% usage to 10, with the highest interest of any build tool on the list. Vite now sits at 98% satisfaction against Webpack's 26. The direction of travel is not subtle. So who is paying for all of this? A lot of it runs through one company, Its entire pitch is to build a single, unified toolchain for JavaScript. Vite, Vytest, Rolldown, and Aux under one roof, all sharing that Rust core. It raised a seed round, then $12.5 million in a Series A. These are open source tools, with real venture money behind them now. And then, this June, the move that made people sit up straight. Cloudflare, one of the biggest infrastructure companies on the internet, acquired VoidZero outright. The Rust toolchain that builds the modern web is now owned by a company that already runs a huge slice of the modern web. Cloudflare also put a million dollars into keeping Vite independent, and Evan-U stays on, leading the open source side. Why would a company like Cloudflare want a bundler? Because whoever controls the tools that build every app controls a chokepoint. If the toolchain is fast, integrated, and yours, you get to shape how the whole ecosystem deploys, tests, and ships its software. This was not really about saving a few seconds on a build. It is about owning the ground the entire JavaScript world happens to stand on. The money numbers back the code numbers, too. SWC pulls over 40 million downloads a week. Rolldown, barely a year old, already does more than 20 million. These are not experiments a handful of enthusiasts run on weekends. They are load-bearing pieces of the internet's plumbing, downloaded tens of millions of times every week, mostly by people who have no idea Rust is anywhere in the picture. Step back, and the shape gets clear. A single Rust engine at the very bottom. A ring of familiar tools sitting on top of it. The bundler, the linter, the compiler, the formatter. Each one a JavaScript name you already know. Each one now running on machine code you rarely see. The names stayed exactly the same. The engine underneath them got swapped out while you were shipping features. Now the honest half, because a lot of Rust videos stop before this and they are wrong too. It is not only Rust doing this. The tool that arguably kicked off the whole movement, SBuild, is written in Go, not Rust. And SBuild is brutally fast. In plenty of benchmarks, it beats SWC, which is the Rust one. So the lesson is simpler than Rust worship. A compiled, parallel language beats an interpreted, single-threaded one, whichever one you happen to pick. And the single biggest speed story of 2026 is not Rust at all. Microsoft rewrote the TypeScript compiler, the thing that typechecks basically every serious JavaScript project, and it shipped this July about ten times faster. They wrote it in Go, not Rust. The tool sitting at the center of the entire TypeScript world picked the other language, and that is a real dent in any pure Rust victory lap. And the reason they picked Go is genuinely interesting. Anders Heilsberg, who created TypeScript, said the existing compiler was full of shared, mutable, pointer-heavy data structures, and that style ports almost directly to Go, but fights Rust's borrow checker at every step. Porting to Rust would have meant redesigning the whole thing from scratch. Sometimes the safety Rust gives you is exactly the friction you do not want. Honest tradeoffs, both directions. Then there is BUN, the fast all-in-one runtime people keep bringing up. For years, it was the clean counterexample. BUN is fast, and BUN was written in ZIG, a third language, not Rust. But even that is shifting. In 2026, the BUN team started rewriting it from ZIG into Rust. For the memory safety, the same borrow checker seatbelt. So the counterexample is slowly joining the very trend it used to disprove. Let me steelman the other side one more time. A skeptic could say this is just people picking faster tools, and the language underneath is a footnote the users did not pick on purpose. And there is truth in that. A developer switches to Vite because it is fast, not because it is Rust inside. But that is the whole point. When the fast option keeps turning out to be the Rust one, over and over, the footnote becomes the story. Here is the line that actually matters, though. None of this touches the code you write, your components, your routes, your business logic, that stays JavaScript and TypeScript. You are not being asked to learn Rust to build a web app. The Rust lives under the floorboards, in the tools. You get all of the speed without paying the learning cost. That is the whole reason this could spread so far, so fast. And to be precise, because precision is the point here. Node itself is not being rewritten in Rust. Node's core is still C++ and V8 and a lot of JavaScript, and there is no serious effort to change that. When people say Rust is eating the JavaScript backend, they mean the toolchain around Node. The builders, the checkers, the runtimes. Not Node's own guts. The engine room is still the old engine room. So what is the honest headline? Compiled systems languages are taking over the JavaScript toolchain, and Rust is the frontrunner, not the whole field. Go is right there beside it. Zig showed up too. But when you count the new tools being built right now, the bundlers, the linters, the formatters, more of them are Rust than anything else, and the momentum is clearly pointing one way. So what does this actually mean for you? Mostly, your tools get dramatically faster while you do almost nothing. Update Next.js, and TurboPack is already there. Start a Vite project, and Rolldown is under it. Swap EastLint for OxLint or Biome on an idle afternoon, and watch a minute-long check turn instant. The upgrade path here is almost boringly painless, and there is a bigger idea worth sitting with for a second. For a decade, the JavaScript answer to a slow tool was to write a better JavaScript tool. That era is ending. The new answer is to drop down one level, write the hot part in a language built for raw speed, and hand it back up wearing an NPM package's clothes. Your ecosystem is being rebuilt from the inside, one tool at a time. Should you go learn Rust because of all this? For most web developers, genuinely, no, not for this reason. You will get every ounce of the benefit without writing a single line of it. But if you have ever been curious about what actually sits under your tools, this is the most useful moment in years to take a look. The floor of your ecosystem is being replaced, and for once, you can watch it happen. My honest take, after going through all of it, this is the healthiest kind of change, the kind you feel as things simply getting better, with no migration and no rewrite demanded of you. Rust and its Go and Zig cousins are not here for your job or your language. They are here for the slow parts of your tool chain, and on that narrow, specific fight, they are winning. If your builds have gotten faster lately and you could not figure out why, now you know what changed down there. What is the last tool in your stack you would expect to see rewritten in Rust? I have a guess. Tell me yours.