WebAssembly Outside the Browser: Real Promise, Real Gaps

Everyone keeps telling me WebAssembly is going to replace containers. I don’t buy it. Not yet. But I’m paying attention, because the parts that work already work really well.

What actually makes sense

Wasm outside the browser has a few properties that are hard to get anywhere else. Near-instant cold starts. True sandboxing where the host decides exactly what the guest can touch. Tiny binaries you can ship anywhere. If you’re running short-lived functions at the edge or loading untrusted plugin code, these properties matter more than anything Docker gives you.

Edge computing is the obvious winner here. Cloudflare Workers already proved the model: run user code in tight sandboxes, spin up fast, tear down fast. Wasm formalizes that. Plugin systems are the other sweet spot. I’ve dealt with enough “just run their code in a subprocess” architectures to appreciate a sandbox that doesn’t require a container per tenant.

The gaps: WASI, threads, Go support

WASI networking is basically nonexistent right now. You can read files if the host lets you. That’s about it. Threading support is patchy. Debugging is painful. If your service needs to open a socket or talk to a database, you’re going to have a bad time.

I’ve been following the Go side of this closely. Go can compile to Wasm, but only for the browser, and the binaries are big. TinyGo gets you much smaller binaries, but it has no WASI target yet, and it’s a subset of Go. Not all standard library packages work. Reflection is limited. You hit walls fast. Rust is in a much better position here: it already has a WASI target and the tooling is good. Go’s story will get there, but we’re not there yet.

The hype I’m skeptical of

Blockchain smart contracts in Wasm. Replacing Kubernetes with Wasm runtimes. Running your entire backend as Wasm modules. These are conference talk ideas, not production architectures. The gap between “cool demo” and “thing I’d run at 3am” is enormous.

I watched the same pattern play out with microservices. The concept was sound. The early adopters built real things. Then everyone decided they needed it for their CRUD app and created distributed monoliths. Wasm outside the browser is at the “concept is sound” stage. Let’s not skip ahead.

What I’m actually doing with it

Experimenting. I compiled a small data transformation service to Wasm and ran it in Wasmtime. Cold start was impressive: under a millisecond. Binary was tiny. But I hit the WASI wall the moment I needed HTTP. Ended up passing data through stdin/stdout like it was 1985.

The capability-based security model is the part I keep coming back to. A process that can’t access anything you didn’t hand it beats one you trust not to escape. That’s a better model for multi-tenant anything.

When I’d use it

For edge functions, plugin systems, and sandboxed execution, Wasm outside the browser is usable today. For everything else, it’s a promising prototype. I’d start experimenting now, but I wouldn’t migrate anything critical until WASI networking lands and the tooling matures. That’s not happening next quarter.