WebAssembly Use Cases: Browser, WASI Server, and Edge Compute

WebAssembly conversations keep talking past each other because a single word covers three very different architectural bets. A frontend engineer hears “makes the web fast,” a backend engineer hears “replaces containers,” a platform engineer hears “powers the edge,” and all three are partially right. Match your problem to one of the three before evaluating a single runtime; if none of them describes your architecture, skip Wasm for now.

WASM in 30 Seconds#

One bytecode, three separate bets: performance in the browser, a WASI runtime on the server, compute at the edge.

Source languages like Rust, C, C++, Go, AssemblyScript, and Zig compile down to a binary instruction format: the .wasm file. The bytecode is stack-based, memory-safe, sandboxed by default, designed to run at near-native speed, and indifferent to the host it runs on.

In-Browser Performance#

JavaScript is not fast enough for a CPU-bound job, so the browser pitch is narrow: compile the existing C++ or Rust codebase and ship it straight into the tab, which has been possible since 2017.

Figma shipped WebAssembly in 2017 and reported cutting the editor’s load time by roughly 3×, compiling its C++ rendering engine to run inside the browser. Photoshop Web, built on a multi-year collaboration between Adobe and the Chrome team, compiles Photoshop’s C++ core via Emscripten and launched a public web beta in 2021.

Wasm has no direct DOM access. Every time Wasm code reaches for a DOM node, an attribute, or an event, the call crosses a JavaScript-to-Wasm bridge that is not free, which is why “just use Wasm instead of JavaScript” is the wrong mental model: Wasm handles the compute inside the application, and JavaScript keeps the interface. This bet is also the most mature of the three: all four major browsers ship it, the platform itself is settled, and the open design questions now live around Emscripten, memory layout, and multi-threading via SharedArrayBuffer.

WASI on the Server#

WASI lets isolated, polyglot workloads run on the server without booting a full container, trading Docker’s weight for a smaller sandbox and faster cold starts, though its ecosystem is younger than what containers have built up.

WASI (the WebAssembly System Interface) is the standardized surface that lets Wasm code talk to files, clocks, sockets, and environment variables without caring which OS is underneath. WASI has two active versions. Preview 1 is the older, POSIX-ish API still widely deployed. Preview 2 shipped on 25 January 2024, was rebuilt on top of the Component Model, and rethinks WASI as a set of typed interfaces rather than syscalls. Preview 3 (WASI 0.3) is already in release-candidate rollout on Wasmtime, with async support and native threads in scope; the 1.0 cut is expected late 2026 or early 2027.

Wasmtime, stewarded by the Bytecode Alliance and backed by the Cranelift code generator, is the reference runtime; Wasmer offers its own packaging and distribution model as an alternative. One layer up, wasmCloud builds a platform on Wasm components and NATS messaging. The component-portability thesis behind that pairing gets its own treatment in wasmCloud + NATS: an event-bus portability bet.

The Component Model itself is still stabilizing: Preview 2 is the stable milestone, and Preview 3 is only a release candidate. Solomon Hykes’ 2019 remark that WASM plus WASI in 2008 would have prevented the need for Docker is a good long-term framing, but in 2026 it stays a vision statement. Library coverage, language support, and tooling still vary by runtime.

Edge Compute#

At the edge, the constraint is geography: users are spread out, and per-request code needs to run close to them without container cold-start costs. Wasm’s cold start lands in the millisecond range against a container’s seconds, and its sandbox is cheap to spin up per request.

Cloudflare Workers pairs V8 isolates with Wasm modules through the official workers-rs crate for Rust, while Fastly Compute skips the V8 wrapper for a pure Wasm-based runtime with a different isolation story and performance profile. Shopify Functions takes a different angle: merchants ship Wasm modules (compiled from Rust, JavaScript, or AssemblyScript) that run inline in Shopify’s checkout and discount paths, making it a customer-extensible commerce-logic platform.

Each edge platform exposes its own KV store, queue, binding ABI, and runtime shape, so the bytecode is portable but the host bindings are not. A Wasm module built for Cloudflare Workers is not a drag-and-drop deploy to Fastly Compute or Shopify Functions. Bindings are where the lock-in hides, which is what the related wasmCloud + NATS portability post explores in depth. For a hands-on look at what shipping a CPU-bound module to the V8-plus-Wasm edge actually involves (and where its three hard limits will bite), see Deploying a WASM Image-Resize Module to Cloudflare Workers.

Which Axis for Which Job#

With the three bets named, the decision turns into a short tree.

Closing#

Start with Bet 1 if the browser is already in your daily surface area and you have a CPU-bound pain the JavaScript engine cannot swallow. The server and edge bets are worth revisiting once WASI Preview 3 stabilizes out of release-candidate status and the runtime ecosystem thickens.

References#

• WebAssembly.org (opens in new tab) - The official home of the WebAssembly standard; the authoritative reference for what the bytecode covers.
• MDN WebAssembly overview (opens in new tab) - Developer-facing concept index covering JavaScript-to-Wasm integration, memory, and tooling guides.
• WASI.dev (opens in new tab) - Official WASI portal; names the Preview 1 vs Preview 2 distinction and lists the active runtime ecosystem.
• Bytecode Alliance (opens in new tab) - Nonprofit stewarding Wasmtime, WASI, and the Component Model; the member list shows who is backing server-side Wasm.
• WebAssembly/component-model (GitHub) (opens in new tab) - Current Component Model repository; the README documents which preview is the active milestone and what is scoped for the next one.
• WASI 0.2 launch (Bytecode Alliance) (opens in new tab) - Dates the Preview 2 vote to 25 January 2024 and walks through the Component Model rationale.
• Figma blog: WebAssembly cut Figma’s load time by 3× (opens in new tab) - Evan Wallace’s 2017 write-up; the canonical in-browser Wasm case study.
• Photoshop’s journey to the web (web.dev) (opens in new tab) - Adobe and Chrome team’s multi-year case study on compiling Photoshop’s C++ core via Emscripten.
• Cloudflare Workers: Rust language support (opens in new tab) - Official documentation for the V8-isolate-plus-Wasm edge model and the workers-rs crate path.
• Fastly Compute product page (opens in new tab) - Fastly’s first-party positioning of a pure-Wasm edge runtime, useful as a contrast to the V8-wrapped model.