More and more applications that look like JavaScript hide their heavy lifting in Rust modules compiled to WebAssembly (Wasm). The interface is still React, HTML or a desktop webview, but large-file processing, compression, rendering and parsing run in a portable, sandboxed binary that is often much faster. Developer Jesús Pérez Mojica recently described it on Medium as the “secret backend” of high-performance apps. Here is what sits behind that idea, the data that supports it and where it still falls short.

Key points in 20 seconds

The pattern: the UI stays in JavaScript and the hot path moves to Wasm. Nobody rewrites the whole app.
Why now: WebAssembly 3.0 shipped in September 2025, and browser support covers roughly 95% of global usage.
Where it already runs: browsers, the edge (Cloudflare Workers), Tauri desktop apps and plugin systems.
The catch: crossing the JavaScript–Wasm boundary constantly eats the gains; it shines on dense computation, not everywhere.

A layer users never see

WebAssembly was designed to complement JavaScript, not replace it. That is how MDN frames it, and the Rust project pitches the same idea: improve existing JavaScript code one module at a time. The result is a split that keeps showing up in real products: a product shell where iteration is fast and hiring is easy, and a performance core where correctness, portability, isolation and speed matter most.

For a sysadmin, that core does not always live on a traditional server. It can be a module running inside a browser tab, the engine of a desktop app or a function deployed at the edge. Users only notice that the app opens quickly, handles large files without freezing and does not fight the browser.

Why the timing finally works

A few years ago Wasm felt experimental. Today it looks like infrastructure. The WebAssembly working group released version 3.0 of the standard in September 2025, with long-awaited features: a 64-bit address space, multiple memories per module, garbage collection, exception handling and relaxed SIMD. Major browsers already ship it, and Can I Use puts WebAssembly support at around 95% of global browser usage.

Outside the browser, the ecosystem has matured too. WASI, the standard interface for running Wasm on servers, edge nodes and devices, has a stable 0.2 release built on the Bytecode Alliance’s Component Model, which defines how modules written in different languages fit together. The next iteration adds native async support, a key piece for network services. The ecosystem is not finished, but it is no longer just a browser trick.

Why Rust fits so well

Rust has no runtime and no garbage collector, and its ownership model guarantees memory and thread safety at compile time. Those properties match what Wasm wants: compact, deterministic, portable code running in a sandbox. A binary without a garbage collector is smaller and starts faster, and the memory bugs that become vulnerabilities in C or C++ are caught before they reach production.

The toolchain helps. wasm-bindgen generates the bindings between Rust and JavaScript, only for what you actually use, and wasm-pack packages the result for the browser or Node.js. A basic workflow looks like this:

cargo install wasm-pack
cargo new --lib engine
cd engine
# in Cargo.toml: crate-type = ["cdylib"] and the wasm-bindgen dependency
wasm-pack build --target web --release
# pkg/ now holds the .wasm file and a JS module ready to importCode language: PHP (php)

The numbers: real, but not magic

The most cited cases are old, but they remain the best documented. In 2017 Figma reported that moving its engine to WebAssembly cut load time by more than three times, regardless of document size. In 2018 Mozilla rewrote the hottest part of its source-map parser in Rust compiled to Wasm and measured speedups of up to 5.89x on realistic benchmarks, later up to 10.9x after further algorithmic work. Its takeaway: convoluted, performance-tuned JavaScript had been replaced by idiomatic Rust that was also faster.

Beyond the browser, academic work on edge serverless runtimes points the same way, with caveats: ahead-of-time compiled Wasm images can be far smaller than containers and cold-start faster, but interpreted Wasm can perform worse once warm and under heavy I/O. The gain is workload-shaped. It is large when you move a chunky compute path and small, or negative, when you recompile half the frontend without a plan.

Far beyond the browser tab

Edge: Cloudflare Workers lets you write entire functions in Rust with the worker crate, compiled to Wasm and run on V8 close to the user.
Desktop and mobile: Tauri 2.0 builds apps for Linux, macOS, Windows, Android and iOS with the UI in the system webview and the core in Rust. The project cites binaries as small as 600 KB, compared with hundreds of megabytes for a typical Electron app.
Rust UIs: frameworks such as Leptos, Dioxus and Yew let you write the interface in Rust too, with server-side rendering and hydration.
Plugins and devices: WASI targets sandboxed plugin systems and constrained devices, where portability and isolation matter more than squeezing out every cycle.

A close-to-home example: PDFs that never leave the device

At Color Vivo, the publisher of this site, we use this pattern in our own projects. files.co and reader.me offer more than 30 PDF tools (merge, split, compress, sign, fill forms, OCR, convert to PDF/A, strip active content) that run entirely in the browser through WebAssembly. Files are never uploaded to a server, which anyone can verify in the browser DevTools network tab, and reader.me even works offline as an installable web app. OCR, for example, runs locally with Tesseract compiled to Wasm.

This is where Wasm makes the biggest difference: processing sensitive data such as contracts, payroll or ID documents without the risk and legal liability of storing them on someone else’s server. For a sysadmin, it also removes the need to run a backend that receives and processes those files.

Rust also works outside Wasm, in native systems tools. mboxShell, another of our open-source projects, is a terminal MBOX viewer written in Rust that opens mailboxes over 50 GB with a streaming parser and a persistent index. It ships as a single binary for Linux (x86_64, ARM64 and RISC-V), FreeBSD, macOS and Windows, receives third-party contributions and is packaged in distributions such as NixOS. CrawlForge is an open-source SEO crawler in Rust, licensed under Apache 2.0, that stores results in SQLite, diffs crawls against each other and applies 59 audit rules with no Java or browser dependency.

The catches that still matter

WebAssembly does not remove JavaScript. To create DOM nodes or open network connections, a Wasm module still has to call out to JavaScript, as Figma’s team noted. That boundary has a cost: Mozilla moved the whole parsing pipeline into Wasm instead of porting individual helpers precisely because every crossing adds overhead. The sweet spot is work that can stay inside Wasm for a while: parsing, simulation, codecs, compression, image and document transforms.

There are platform limits too. Rust’s wasm32-unknown-unknown target is deliberately minimal: println! does nothing, std::fs returns errors and std::thread::spawn panics. For system access you need the WASI targets, such as wasm32-wasip1 or wasm32-wasip2:

rustup target add wasm32-wasip2
cargo build --target wasm32-wasip2 --release
wasmtime target/wasm32-wasip2/release/app.wasm

Debugging is still clumsier than in JavaScript, and binaries can get heavy unless you optimize them (opt-level = "z", LTO and tools like wasm-opt). None of this breaks the pattern, but it is worth knowing before you pitch it to a team.

The realistic bet

The sensible reading is not “rewrite the web in Rust”. It is to find the part of an app that is slow, memory-sensitive or hard to trust and move it into a Rust core compiled to Wasm. It is the same logic that took Rust into the Linux kernel, where it is now a permanent part of the kernel, although in the browser it does not always pay off: some projects deliberately skip Wasm, like JSQLite, which brings SQLite to the browser in pure TypeScript. If the pattern keeps spreading, users will never know they are touching Rust. They will just notice the app loads faster, handles bigger inputs and breaks less often.

Frequently asked questions

Does WebAssembly replace JavaScript?

No. It is designed to complement it. JavaScript still handles the UI, the DOM and networking, while Wasm takes on compute-heavy tasks.

Why is Rust so popular for WebAssembly?

It has no garbage collector or runtime, produces compact binaries and guarantees memory safety at compile time. It also has mature tooling such as wasm-bindgen and wasm-pack.

Is Wasm always faster?

No. It pays off on dense computation that stays inside the module. If code constantly crosses the JavaScript boundary, the overhead can cancel the gains.

Can WebAssembly run outside the browser?

Yes. With WASI and runtimes like Wasmtime it runs on servers, at the edge (for example on Cloudflare Workers), in plugin systems and on embedded devices.

Source: Jesús Pérez Mojica on Medium, plus documentation from WebAssembly, Rust, MDN, Figma, Mozilla, Cloudflare and Tauri