Rust and WebAssembly: Benchmark Before You Bet

In December 2022 I wrote a getting-started post on Rust and WebAssembly in a React app: install Rust and wasm-pack, compile a module, load it from a component, and call an exported function. The example was Fibonacci. It was the post of someone who’d just got it working and was excited, which is a perfectly good reason to write.

Four years on, I’d write a different post. Not “how do I set this up?” but “when is it worth it?”

When Wasm earns its place

WebAssembly runs compiled code in the browser at near-native speed. Rust is a good source language for it: no garbage collector, strong types and great tooling. That makes it a fit for work that is:

• CPU-bound: parsing large binary payloads, aggregating thousands of rows, physics, image or audio processing, graph layout.
• Self-contained: a function that takes a chunk of data and returns a result, rather than something that chats with the DOM all day.
• Already proven slow in JavaScript, by a profiler, not by a hunch.

Fibonacci is none of those things in a real app, which is the honest critique of my own example.

The boundary has a cost

Calling into Wasm isn’t free. Data has to cross from JavaScript’s memory into Wasm’s linear memory and back. If you call a Wasm function thousands of times per frame with small arguments, the crossing can eat the gains. The pattern that works is to batch: hand Wasm a big buffer, let it do a lot of work, take back a result.

And Wasm doesn’t touch the DOM directly. For UI-heavy work, the bottleneck is usually rendering, not computation, and Wasm won’t help there. In the real-time trading UIs I build at a fintech, the wins have come from rendering less (Zustand Transient Updates), not from computing faster.

The landscape moved

Some of the tools in my 2022 post have changed hands or faded. The old Rust–Wasm working group’s GitHub organisation was archived in 2025, with key projects like wasm-bindgen moving to new maintainers. If you’re starting today, check what’s actively maintained before you copy a 2022 tutorial, including mine.

How I’d approach it now

1. Profile first. Find the hot path with the browser’s performance tools.
2. Try the cheap fixes: a better algorithm, a Web Worker to get off the main thread, fewer renders.
3. Prototype the hot path in Rust, behind the same interface, and benchmark it against the JavaScript version with realistic data.
4. Keep it only if the numbers say so, and the team is willing to own a second language.

That’s why Rust + WebAssembly sits in “assess” on my radar: promising for specific hot paths, but something you earn with a benchmark, not adopt with enthusiasm. I have an experiment queued to test exactly that with a dense live chart.

Rust itself has been an on-and-off learning project for me for years. The language changed how I think about ownership and data flow even in TypeScript, which might be its biggest benefit to a front-end developer.

---

Originally written in 2022 → Rust and web assembly