8 WebAssembly Use Cases That Prove the Browser Was Just the Beginning

The technology that started in the browser is now powering cloud platforms, serverless functions, and high-performance systems.

Solomon Hykes, the person who created Docker, posted something in 2019 that most engineers skimmed past. He wrote that if WebAssembly had existed in 2008, Docker would never have needed to exist.

That sentence should have stopped people cold. It did not. Most developers filed it under “interesting hyperbole” and moved on. That was a mistake.

The reason Hykes said that only makes sense once you understand what WebAssembly actually isolates — and it is not what the browser demos taught you.

WebAssembly does not isolate operating systems. It isolates memory and capabilities. A Wasm module cannot access the filesystem, the network, or the clock unless you explicitly hand it those capabilities. No kernel call. No namespace juggling. No cgroup configuration. That is a fundamentally different trust model than containers, and it opens up architectural possibilities that have almost nothing to do with browsers.

Here are eight places that model is being put to work right now.

The Serverless Cold Start Problem, Finally Solved at the Root

AWS Lambda cold starts in Node.js hover between 200ms and 400ms on a quiet container. Fastly’s Compute platform, built on Wasmtime, runs Wasm modules in under 50 microseconds. That is not a tuning improvement. That is a different execution model entirely.

The reason is straightforward. A Wasm module does not need an OS process or a language runtime to warm up. The sandbox is lightweight enough that Fastly spins up a new one per request, for every request, without pooling. Cloudflare Workers uses the same approach. This is the architecture:

+----------------+       +-----------------------+
|  HTTP Request  |  -->  |  Wasm Isolate (new)   |
+----------------+       +-----------------------+
                              |           |
                        [memory limit]  [capability list]
                              |           |
                         no FS access   no net access
                         unless granted unless granted

No persistent process to keep warm. No JIT cache to prime. The module starts at the instruction boundary, runs, and exits. When you think about what a serverless platform actually needs — isolation, fast startup, predictable memory — Wasm fits better than a container runtime at this specific scale.

Plugin Systems That Cannot Burn Down the Host

Every engineer who has built a plugin system for a long-running service has a story about the plugin that took down the host process. A segfault in a shared library. A memory leak in a third-party module that nobody owned. An infinite loop in a customer-supplied script that pinned a thread.

Wasm solves this structurally. The module runs in its own linear memory space. It cannot write outside that space. If it crashes, the host catches a trap and continues.

Extism is a library that wraps this pattern cleanly, and teams at companies like SingleStore and Envoy maintainers are using it for exactly this reason.

The code to run an untrusted plugin safely looks like this:

javascript

import { Plugin } from "@extism/extism";
const plugin = await Plugin.fromFile("./user_plugin.wasm", {
  useWasi: true
});
const result = await plugin.call("transform", inputBuffer);
// if plugin panics, this throws - host keeps running

Compare that to spawning a subprocess, managing IPC, handling crashes via process exit codes, and cleaning up file descriptors. The Wasm version is four lines. The safety is structural, not convention-based.

The Eight Use Cases, Grounded

The browser use case is the one everyone knows — porting compute-heavy code like image processing, codecs, or physics engines to run near-natively in a tab. That is real and it works. But it is the least interesting thing on this list.

• Serverless edge functions are the commercial story right now. Cloudflare, Fastly, and Fermyon are all building on Wasm runtimes because the isolation-per-request model is cheaper to operate than container pools.
• Embedded plugin systems — described above — are the use case that will quietly change how B2B SaaS platforms handle extensibility. Salesforce runs Apex in a Wasm sandbox. Shopify ran checkout customization logic this way before they rebuilt it.
• Database extensions are a newer frontier. SingleStore lets users write custom functions in Wasm. The function runs inside the query engine with direct access to row data but zero access to the network or filesystem. The query engine does not trust the extension. It just hands it memory.
• WebAssembly System Interface (WASI) is the piece that makes server-side Wasm coherent. WASI defines a standard set of system calls — file access, clocks, random numbers — that a Wasm module can request. A runtime like Wasmtime implements those calls. This means you can write a command-line tool, compile it to Wasm, and run it on any machine that has a WASI-compatible runtime. Same binary. No recompile. The portability promise that containers made, but without the OS layer.
• Kubernetes sidecars are an emerging use case that surprised me personally. At a previous company, we ran a logging interceptor as a sidecar that was consuming 80MB of RSS doing nothing except tailing a socket. A team I know replaced a similar pattern with a Wasm module run via the containerd-shim-spin project. Same behavior, 3MB memory footprint, sub-millisecond startup. The pod scheduler became noticeably happier.
• AI inference at the edge is the newest entry. ONNX models compiled to Wasm and served via Fastly or Cloudflare mean you can run a small classification model at 200+ edge nodes without deploying GPU instances. The model is the binary. The runtime is already there.
• Confidential computing is the long-term bet. Wasm’s deterministic execution and explicit capability model make it a natural fit for trusted execution environments. If the module cannot call arbitrary syscalls, the attestation model becomes much cleaner. Projects like Enarx are building on exactly this property.

The Mental Model That Ties This Together

WebAssembly is not a compilation target. It is a trust boundary.

Everything interesting about Wasm in production comes from that sentence. A container gives you OS-level isolation with process semantics. Wasm gives you capability-level isolation with function semantics. Those are different tools for different problems. Containers are the right answer for running a web server. Wasm is the right answer for running code you do not fully trust inside a system you need to keep running.

Once you hold that mental model, the eight use cases above collapse into one pattern: untrusted or unpredictable code, running inside a system that needs to stay healthy, with explicit control over what that code can touch.

Where This Breaks Down

Wasm is not a universal answer. The ecosystem around WASI is still maturing — file handling, threading, and async I/O have all gone through multiple incompatible drafts. The Component Model, which is the spec for composing Wasm modules together, is stable enough to use but young enough that you will hit rough edges.

Debugging a Wasm module in production is harder than debugging a native binary. Source maps help in browsers. In server-side runtimes, the tooling varies. If you are running Wasmtime in a custom embedding, you are writing your own debugger hooks.

And compilation times matter. If your build pipeline compiles Rust to Wasm, the incremental compile experience is fine. If you are compiling a large Go codebase, the output binary size and compile time can be genuinely painful.

Use Wasm where the trust boundary problem is real. Do not use it because it is interesting.

The Checklist for Monday

Before adding Wasm to a project, run this check:

• Is there code I need to run that I do not fully control or trust?
• Do I need sub-millisecond startup for isolated execution?
• Do I need the same binary to run on multiple runtimes or architectures?
• Am I building an extension or plugin system that could be abused by a bad actor or just bad code?

If two or more of those are true, Wasm is worth a serious evaluation. If none are true, a container or a subprocess is probably simpler.

The browser was where WebAssembly was born. It is not where WebAssembly is going. The engineers who understand that distinction before their competitors do are going to build some interesting things over the next three years.

If this framing changed how you think about Wasm’s role in your stack, the next article in this series covers the WASI Component Model — which is the missing piece that makes Wasm modules composable at scale.