Rust Is Taking Over the JS App Stack

My name is Max and I'm the founder of Rustify.

I've been writing Rust professionally for 2 years and I've helped dozens of engineers make the switch to Rust professionally.

If you want to go further, here's how I can help:

• Fullstack Bootcamp: structured program with real projects, async support, and private community access.
• Blockchain Bootcamp: structured program with real projects, async support, and private community access.
• 1:1 Mentorship: personalized sessions to get you hired faster, with projects tailored to you and mock interviews.

And if you want more Rust content, I post regularly on my YouTube channel:

First name

Email

Send me the PDF →

No spam. Unsubscribe any time.

First name

Email

Get it

If you're reading this, you probably already feel the ceiling.

At some point, JavaScript apps start to feel heavier than they should. The desktop binary is too big. The API spikes under load. The Lambda wakes up too slowly. The mobile layer needs another workaround just to hide the bridge. Nothing is fully broken. It just stops feeling serious.

Plenty of developers accept that as normal. The app works. The users tolerate it. The team ships anyway.

You probably do not.

At some point, you start asking a different question: what would this app feel like if the implementation layer were more serious?

This guide is about that shift.

Big Picture

RUST IS TAKING OVER THE JS APP STACK
│
├── DESKTOP APPS       Electron → Tauri
├── CROSS-PLATFORM UI  React Native / Flutter → Dioxus
├── BACKEND / API      Express / Fastify → Axum / Actix-web
├── NATIVE MODULES     C++ addons → NAPI-RS
└── EDGE / SERVERLESS  JS Workers → Rust Workers (Cloudflare, AWS Lambda)

1. You Already Run Rust (and You Don't Know It)

You did not choose Rust. You did not install it. You do not think about it. But it is running on your machine right now, inside the tools you use every day and the apps your users download.

There are two layers where this is already happening.

The tooling layer

Every time you run next build, vite build, or npx tailwindcss, you execute compiled Rust code. The npm package is a thin JavaScript wrapper that downloads a native binary and calls it. The Rust logo is not on the package. The speed is.

*Rewritten from Zig to Rust in May 2026 by Anthropic. 960,000 lines in six days. Zero breaking changes.

The app and platform layer

Beyond tooling, the apps your users install and the platforms your code runs on are also moving to Rust.

None of these were announced as "Rust projects." They were announced as performance improvements, binary size reductions, or reliability fixes. Rust was the implementation detail.

The question

You are not choosing whether to use Rust. You already use it. The question is whether you write it, or whether you only benefit from the work of teams that do.

That is the line many mentorship clients are crossing now: from benefiting from Rust indirectly to building and deploying real apps with it directly.

2. The Problem With the JS App Stack

JavaScript was designed to run small scripts in a browser. In 1995, it animated dropdown menus. In 2025, it runs desktop apps, mobile apps, production APIs handling millions of requests, and serverless functions invoked thousands of times per second.

The language did not change to fit those workloads. The workloads just grew until the mismatch became impossible to ignore.

Desktop: Electron

Electron is the reason VS Code, Slack, Discord (originally), Figma (originally), and hundreds of other desktop apps exist. It made cross-platform desktop development possible with web skills. That is genuinely good.

It also means that every Electron app ships its own copy of Chromium. Not the one already on your machine. A private copy, bundled into your installer, sitting in the user's Applications folder forever. That is 80-100 MB of browser engine per app, before you write a single line of application code. VS Code is an Electron app. It is also 300 MB. You have been carrying a spare browser in your dock this whole time.

Then there is security. Every Electron app carries its own Chromium CVEs. When a browser zero-day drops, your users are running the vulnerable version until you ship a patch, they notice the update, and they install it. On Tauri, the system webview gets patched by the OS like any other system component. Your users are protected before you even know there was a vulnerability.

Mobile: React Native

React Native made it possible to write mobile apps in JavaScript. The tradeoff was the bridge: a communication layer between the JavaScript runtime and native platform APIs. Every time your JS code calls a native function, the call crosses the bridge. The bridge is synchronous. It is a bottleneck by design.

React Native's New Architecture (Fabric and JSI) exists entirely to address this. Years of engineering, a complete rewrite of the rendering layer, a new interop system. The result: a faster bridge. The bridge is still there. Dioxus does not have a bridge. There is nothing to work around.

Backend: Node.js

Node.js runs the backends of some of the largest companies in the world. It handles millions of requests per day for Uber, Netflix, LinkedIn. It is genuinely capable. But it is single-threaded by design, and that design was chosen for a specific reason that has nothing to do with your API.

Ryan Dahl built Node.js to handle concurrent HTTP connections without threads. Threads were expensive, error-prone, and hard to reason about. An event loop that switches between I/O-bound tasks was simpler. It was the right call for the problem he was solving.

Your API is probably not that problem. If your handler parses a large payload, compresses a file, or runs any CPU-bound logic, the event loop becomes the bottleneck. There is one thread. If it is busy, every other request waits behind it. You can add Worker threads to work around this. Now you are managing Worker threads in JavaScript. The cure has its own complications.

Under traffic spikes, the GC also picks the worst possible moment to run. Pauses happen when the heap fills under load, precisely when you need the lowest latency. The GC has terrible timing. It always has. GC spikes under load are the #1 thing I see in production debugging sessions with my clients. On a Rust server, there is no GC. Nothing pauses. The P99 stays flat whether you are getting 100 requests or 100,000.

Serverless: the cold start problem

A Node.js Lambda cold start takes 200-400ms. That is V8 booting, the runtime initializing, your node_modules loading, and your handler finally starting. On the first request after a cold period, your user waits half a second before your function runs a single line of code.

A Rust Lambda cold start takes roughly 1ms. One millisecond. The binary starts, the handler runs. No runtime to initialize, no modules to load, no JIT warmup.

Cold starts are also a cost problem. Lambda is billed per GB-second. A Node.js Lambda running at 512 MB doing the same work as a Rust Lambda running at 128 MB costs four times more at scale.

The root cause

All of these problems share the same origin. JavaScript was built to be easy to run everywhere, not to be fast or memory-efficient at scale. The V8 engine is remarkable engineering that makes JavaScript far faster than it has any right to be. But it cannot overcome the fundamental constraints of a garbage-collected, single-threaded runtime when the workload demands otherwise.

Rust was designed for exactly the workloads where JavaScript struggles: concurrent, CPU-bound, memory-constrained, latency-sensitive. It is not a coincidence that every performance ceiling in the JS app stack is being broken by rewriting the bottleneck in Rust.

3. Tauri — Electron → Tauri

Electron solved a real problem. Before it, building a cross-platform desktop app meant learning Qt or wxWidgets or writing platform-specific code for Mac, Windows, and Linux separately. Electron said: you already know HTML, CSS, and JavaScript. Use that. Ship everywhere.

The price was a 150 MB binary that boots a full browser on startup.

Tauri keeps the idea and replaces the implementation. Your frontend stays in React, Vue, Svelte, or any web framework. The Chromium bundle disappears. Instead, Tauri uses the webview already installed on the user's operating system: WKWebView on macOS, WebView2 on Windows, WebKitGTK on Linux. The shell layer that would have been Node.js becomes Rust.

What that looks like in practice

The frontend stays the same

This is the critical point. You do not rewrite your React app. You do not learn a new component model. The HTML, CSS, and JavaScript in your frontend work exactly as they did under Electron. Tauri wraps them in a native window using the system webview.

What changes is the backend. In Electron, the main process is Node.js. You can use npm packages, read files, talk to databases, spawn child processes, all in JavaScript. In Tauri, the backend is Rust. Your JS frontend talks to it over an IPC bridge:

// Frontend (TypeScript): call a Rust function
import { invoke } from "@tauri-apps/api/core";
 
const result = await invoke("read_file", { path: "/Users/me/data.json" });

// Backend (Rust): handle the call
#[tauri::command]
fn read_file(path: String) -> Result<String, String> {
    std::fs::read_to_string(path).map_err(|e| e.to_string())
}

The Rust backend can do anything a native app can do: access the filesystem, spawn processes, call system APIs, talk to hardware. With no Node.js process in the renderer, the attack surface is significantly smaller than Electron.

Who ships with Tauri

• Zed: code editor built entirely in Rust, using Tauri for the shell
• 1Password 8: rewrote their desktop app with a Rust core and Tauri shell, reduced binary from 300 MB to under 20 MB
• Linear: desktop app, React frontend, Tauri shell
• Cal.com: desktop client

Several of my clients have replicated this pattern with their own internal tools: same React frontend they already had, Rust shell, deployed app, binary drops from 180+ MB to under 8 MB. That is often the cleanest first proof point because the user-facing experience stays familiar while the implementation layer changes completely.

Tauri v2 (2024)

Tauri v2 added mobile support: iOS and Android targets from the same codebase. The Rust backend compiles to native mobile code. The frontend stays web. One codebase for desktop and mobile, no React Native bridge required.

When Electron still makes sense

Tauri is not a drop-in replacement for every Electron app. If your app:

• Depends heavily on Node.js APIs or specific npm packages in the main process
• Has a large existing Electron-specific plugin ecosystem
• Needs a team with no Rust experience and no time to learn

then the migration has a real cost. The Rust learning curve is genuine. For new projects, the tradeoff is obvious. For large existing Electron apps, measure the pain before committing to the rewrite.

4. Dioxus — React Native / Flutter → Dioxus

React Native's pitch was compelling: write your mobile app in JavaScript, ship to iOS and Android. The catch was always the bridge. Every time your JavaScript code touches a native API -- to render a button, read the camera, check permissions -- the call crosses a synchronous boundary between the JS runtime and the native layer. That crossing has a cost. Under heavy interaction, the cost is visible.

The New Architecture (JSI and Fabric) reduces the cost. It does not eliminate the bridge. It is a faster bridge.

Dioxus does not have a bridge. There is no JavaScript runtime at all. Components are written in Rust. They compile directly to native code or to WebAssembly. The gap between your UI logic and the platform below it is zero.

The API

If you know React, Dioxus is readable on day one:

use dioxus::prelude::*;
 
fn App() -> Element {
    let mut count = use_signal(|| 0);
 
    rsx! {
        button { onclick: move |_| count += 1, "Clicked {count} times" }
    }
}

Components, signals (hooks), props, event handlers: the mental model maps directly. The language is Rust. The patterns are React.

One codebase, every target

dioxus target
├── web       → compiles to WASM, runs in the browser
├── desktop   → native window, no webview, uses the GPU directly
├── mobile    → iOS and Android (experimental, stabilizing in 2026)
└── TUI       → terminal UI

The same component tree renders on every target. Not "approximately the same" with platform-specific shims. The same Rust code, compiled differently.

Dioxus vs the field

Dioxus vs Tauri

This is the most common question. Both use Rust. Both target desktop and (increasingly) mobile.

• Tauri: your frontend is a web app rendered in a system webview. You write React or Vue or Svelte. The Rust backend handles native operations.
• Dioxus: your frontend is Rust. There is no webview. The UI renders natively or compiles to WASM.

Pick Tauri when you have an existing web frontend you want to keep, or when your team knows JS better than Rust. Pick Dioxus when you want a full Rust stack, native rendering, and are willing to leave the npm ecosystem behind for the UI layer.

Trade-offs

Dioxus is not a drop-in React replacement. The component ecosystem is small. There is no npm of Dioxus UI libraries. The tooling is improving but not yet at the maturity of React Native or Flutter. The learning curve is Rust's: the compiler will fight you before it helps you. Most developers find it worth it once they get past the initial friction.

Status in 2026: web and desktop stable and production-ready. Mobile in active development, closing fast.

5. Axum — Express → Axum

Express is not slow. It handles hundreds of requests per second comfortably, and thousands with tuning. For most CRUD APIs talking to a database, Express performance is not the bottleneck.

But Express has a ceiling. A single Node.js process runs on one thread. Under CPU-bound load (parsing, transforming, encrypting, computing), that thread becomes the limit. You can cluster Node.js processes to use multiple cores, but you are now managing a pool of processes instead of writing application code.

Axum runs on Tokio, Rust's async runtime. It uses OS threads natively. Every core on your machine is available to a single Axum process. There is no GC. Under the same hardware: Express handles ~10,000 req/s. Axum handles ~300,000.

The API looks familiar

The mental model maps directly from Express. The syntax is different, the structure is not:

// Express
app.get("/users/:id", async (req, res) => {
  const user = await db.findUser(req.params.id);
  res.json(user);
});

// Axum
async fn get_user(Path(id): Path<u32>, State(db): State<DbPool>) -> Json<User> {
    Json(db.find_user(id).await)
}

Two differences worth noting. First: no req object to dig into manually. Axum extracts what you declare in the function signature. Second: if the path param is not a valid u32, Axum returns a 400 before your function runs. No runtime crash. No parseInt check.

Most of my clients coming from Express are writing real Axum endpoints by day two. The mental model is familiar. The compiler is not, but it gets easier fast. More importantly, they stop talking about Rust as a future skill and start shipping deployed backend proof with it.

For a full Axum guide with middleware, state management, and authentication patterns, see the dedicated Axum guide.

30x the throughput of Express on the same hardware. P99 latency stays flat under load instead of spiking with the GC. See section 7 for the full numbers.

6. Actix-web

TechEmpower runs the most comprehensive web framework benchmarks in the industry: 400+ frameworks, multiple workloads, independent hardware. Actix-web has been in the top 5 for years. Not top 5 Rust frameworks. Top 5 globally, across every language, including Go, Java, and C++.

Axum is the ergonomic choice. Actix-web is the choice when you have looked at the benchmarks and want the number at the top of the list.

Actor model

Actix is built on the actor model: each request is handled by a worker thread with its own isolated state. No shared mutable state, no locks, no contention. Every core runs independently at full speed. That is why the throughput numbers are what they are.

Actix vs Axum

Start with Axum. It has better documentation, a larger community, and plugs into the Tower ecosystem. Reach for Actix-web when you have looked at your profiling and Axum itself is the ceiling.

7. Node.js vs Rust Backend: Real Numbers

Benchmarks lie. Synthetic tests optimize for the benchmark, not for real workloads. With that caveat: the order-of-magnitude differences between Node.js and Rust frameworks are real and consistent across independent test suites.

Throughput under load

These numbers are on equivalent hardware, single-node, plaintext responses. Real workloads with database queries reduce the gap (the DB becomes the bottleneck) but do not eliminate it.

Memory per connection

At 1,000 concurrent connections, a Node.js server uses 10x the memory of an Axum server handling the same load. On Lambda, that is 10x the bill.

Lambda cold starts

For user-facing APIs, a 400ms cold start is a 400ms delay your user feels before your code runs a single line.

P99 latency under load

This is where the GC difference is most visible. Under sustained load, Node.js P99 latency spikes periodically as the GC runs. The spikes are predictable (they happen when the heap fills) but unavoidable. A Rust server's P99 latency stays flat under the same load because there is nothing to trigger a pause.

If your SLA requires P99 under 50ms at peak load, Node.js requires careful GC tuning and often still delivers occasional spikes. Rust delivers it structurally. No tuning. No tradeoff. The pauses do not exist.

8. NAPI-RS — C++ Addons → NAPI-RS

You have been calling Rust functions from JavaScript for years. Every time you run SWC, Biome, or Oxlint inside a Node.js project, you are calling a Rust function via NAPI-RS. The npm package downloads a compiled Rust binary. NAPI-RS is the glue that makes it appear as a normal JavaScript import. It just never had a visible name in your stack.

Node.js has always supported native addons for exactly this: compiled code that runs at full CPU speed inside the Node process, with no runtime overhead. The original path was C++. Writing C++ addons is legitimately hard: manual memory management, no thread safety guarantees, node-gyp as the build tool (a reliable source of npm install failures), and a segfault in the addon takes down the entire Node process.

NAPI-RS replaces all of that with Rust. You write a function. NAPI-RS generates the binding. No memory management. No segfaults. No GCC.

use napi_derive::napi;
 
#[napi]
pub fn hash_password(input: String) -> String {
    // CPU-bound work runs in Rust, called from JS like any function
    bcrypt::hash(input, 12).unwrap()
}

// JavaScript side: looks like any other import
import { hashPassword } from "./index.js";
 
const hashed = hashPassword("my-password"); // Rust runs here

This is how the ecosystem already works

NAPI-RS is not experimental. Every major Rust tool that ships to npm uses it:

• SWC: the transpiler Next.js uses is a Rust binary exposed via NAPI-RS
• Oxc, Biome, Rspack: same pattern

When you npm install @biomejs/biome, you get a package.json that downloads a pre-compiled Rust binary for your platform and exposes it through NAPI-RS. The JS side is five lines of glue. The work happens in Rust.

When you need it

Any CPU-bound operation inside a Node.js codebase is a candidate:

• Image processing (resizing, encoding, compression)
• Cryptography (hashing, signing, encryption at volume)
• Parsing (custom formats, binary protocols)
• Video processing
• Anything where a Node.js profiler shows the function itself as the bottleneck

The pattern: keep your application logic in TypeScript, move the hot path to Rust, publish the result as a normal npm package. No language migration. No rewrite. One function at a time.

9. Cloudflare Workers + Rust

Your API probably runs in us-east-1. That is great for users in Virginia. For a user in Tokyo, every request crosses the Pacific Ocean, runs on your server, and crosses the Pacific back. You pay for that in latency, and your users feel it.

Cloudflare Workers runs your code in 300+ data centers globally. The request runs at the edge closest to the user. No ocean crossing. The runtime is V8 isolates managed by a Rust scheduler. Each request gets its own isolate. Isolates start in microseconds. There is no cold start.

You can write Workers in JavaScript. You can also write them in Rust.

Deploying Rust to Workers

Rust compiles to WebAssembly. Cloudflare Workers runs WebAssembly natively. The deployment flow:

cargo install worker-build
worker-build --release
wrangler deploy

Your Rust code runs at Cloudflare's edge, globally, with microsecond startup time. The JavaScript Workers SDK stays available for the parts that do not need Rust.

Why Cloudflare is all-in on Rust

Cloudflare's bet on Rust goes beyond Workers. In 2026 they acquired VoidZero, the company behind Vite+. That means Cloudflare now owns the toolchain (Vite+, Rolldown, Oxlint), the runtime (Workers), and the infrastructure layer. The same language from the build step to the CDN edge.

Cloudflare's network handles roughly 20% of global internet traffic. Their infrastructure runs on Rust. When they acquire the JS ecosystem's unified toolchain and rewrite it in Rust, that is not a side project. That is a direction.

10. AWS Lambda + Rust

Lambda's pricing model makes Rust's memory efficiency worth money. Lambda charges per GB-second: the amount of memory you allocate multiplied by the time your function runs. A Node.js Lambda typically needs 512 MB to handle concurrent requests comfortably. A Rust Lambda handling the same work runs in 128 MB.

Same compute. Four times less memory. Four times cheaper per invocation.

Cold starts

A Node.js cold start is 200-400ms of V8 booting, the runtime initializing, and your node_modules unpacking before a single line of your handler runs. You are not slow. Your infrastructure is slow, and it is slow before you even start. Think about what that means for a user hitting your API after a quiet period: half a second of waiting for a runtime to wake up, before your code runs a single line.

A Rust Lambda is a compiled binary. Boot, run, exit. The cold start is effectively noise.

Cargo Lambda

cargo-lambda is the dedicated toolchain for Rust Lambdas. It handles cross-compilation (building for the Lambda ARM or x86 environment from your Mac), local testing with cargo lambda watch, and deployment with cargo lambda deploy. The development loop is close to what you get with the Serverless Framework for Node.js.

cargo install cargo-lambda
cargo lambda new my-function
cargo lambda watch      # local dev with hot reload
cargo lambda deploy     # builds and deploys to AWS

11. The Pattern: Rust Eating Every Layer

Every platform in software history eventually outgrows its tooling. The tooling gets rewritten in a systems language. The web is not special.

Phase 1 (2010s): JavaScript tooling written in JavaScript
  → Fast to build, accessible to everyone, ecosystem explodes
  → Performance ceiling hit as codebases scale
 
Phase 2 (2018-2024): Individual Rust rewrites
  → SWC replaces Babel
  → Rspack replaces webpack
  → Biome replaces ESLint + Prettier
  → Each tool independently, no coordination
 
Phase 3 (2024-2026): Platform-level consolidation
  → Oxc: one shared parser for all tools
  → Vite+: one CLI for the entire dev cycle
  → Bun: runtime rewritten from Zig to Rust
  → Cloudflare acquires the toolchain
  → Tauri, Axum, NAPI-RS: apps follow tooling

The same language is now running at every layer:

YOUR CODE SHIPS THROUGH RUST AT EVERY STEP
 
Write        → TypeScript (your code)
Build        → Rolldown / SWC / Oxc (Rust)
Lint/format  → Biome / Oxlint (Rust)
Monorepo     → Turborepo (Rust)
Runtime      → Bun (Rust) / Deno (Rust core)
Desktop      → Tauri (Rust shell)
Backend      → Axum / Actix-web (Rust)
Edge         → Cloudflare Workers (Rust runtime)
Serverless   → AWS Firecracker (Rust micro-VM)

You did not choose any of this. The teams maintaining the tools you rely on chose it, one performance ceiling at a time.

12. What Stays in JS

Not everything moves to Rust. Understanding what stays is as important as understanding what is moving.

Your application code stays in TypeScript. Components, business logic, domain rules, API calls, state management: none of this is moving. TypeScript is productive, well-tooled, and the right language for this work.

Framework runtimes stay in JavaScript. React, Vue, Svelte, Solid: the code that runs in your users' browsers stays JS. The browser runs JavaScript. That is not changing.

The npm ecosystem stays. A million packages, decades of accumulated solutions. Rust integrates with it through NAPI-RS when needed, but does not replace it.

What moves is the layer that processes, runs, and executes your code at machine level. The compilers, bundlers, linters, runtimes, servers, and infrastructure that power what you write.

JS stays for what humans write. Rust takes over what machines execute.

That line is already blurring. And the direction is clear.

Most JavaScript developers will benefit from this shift passively. A smaller group will use it to become the kind of engineer who can build and ship inside it.

That group does not just know that Rust is faster. They can evaluate when a Rust rewrite makes sense, lead the conversation, and eventually ship the proof of concept instead of only forwarding the benchmark.

That is the transition I help clients make. Not from zero to hype, but from "I know Rust matters" to deployed apps, real backends, and credible proof that changes how the market reads them.

If you recognized yourself in that second group, the next move is not to save this guide and call it research. It is to pick one serious proof point and build it: one internal desktop tool in Tauri, one real Axum service, or one hot path moved out of Node and into Rust.

That is already the work I do with mentorship clients. We do not stop at "Rust seems important." We build the thing, deploy it, and use that proof to change what becomes possible next.

If you want to make that shift seriously, this is where to start.

Book a call →

If you want to go from knowing these answers to getting hired, with mock interviews, real projects, and personalized feedback on your weak spots, that's exactly what the Rustify Bootcamp and 1:1 Mentorship are for:

• Fullstack Bootcamp: structured program with real projects, async support, and private community access.
• Blockchain Bootcamp: structured program with real projects, async support, and private community access.
• 1:1 Mentorship: personalized sessions to get you hired faster, with projects tailored to you and mock interviews.

First name

Email

Send me the PDF →

No spam. Unsubscribe any time.

First name

Email

Get it