WASM's "Identity Crisis" Is Actually Its Superpower

(Continuing the thoughts from last time...)

I'm an enormous fan of Matt Butcher (CEO of Fermyon) - generally - but I loved this quote, "We haven't hit that key Docker moment yet, But we're getting close."

He's right that we haven't. But, and I probably am a bit contrarian here, I don't think we need one.

The conversation around WebAssembly has become obsessed with finding its "Docker moment" that Solomon Hykes tweet where he said if WASM+WASI had existed in 2008, Docker wouldn't have been necessary. The ecosystem is waiting for WASM to crystallize into a single, obvious use case that everyone can rally around.

This is a bit like fighting the last war. Docker was for centralized clusters. We need a new path for infrastructure that needs to run everywhere.

The "Crisis" Everyone Keeps Diagnosing

RedMonk's Kate Holterhoff captured the developer sentiment perfectly: "What the Wasm 3.0 release highlights for me is its ongoing identity crisis. Is it a faster JavaScript? A way to run legacy code? A universal runtime? If developer discussions are any indication, the jury is still out."

The New Stack's B. Cameron Gain went further: "The component model has not yet been completed. We can say that the great, widely anticipated 'Docker moment' for WebAssembly has not yet been achieved."

But read closer and you'll see what's actually happening. The criticism isn't "WASM doesn't work." It's "WASM works for too many things."

Look at what's already running in production:

MediaPipe ships computer vision models to browsers via WASM, enabling real-time face detection and pose estimation without server roundtrips
Transformers.js runs Hugging Face models entirely in-browser (sentiment analysis, text generation, and embeddings) with zero backend infrastructure
ONNX Runtime Web executes ML models in browsers at near-native speed with a 3-5x performance improvement over pure JavaScript
OpenCV.js provides the full OpenCV library compiled to WASM, powering image processing pipelines that previously required native binaries

That's not one use case. That's four fundamentally different deployment models, all using the same compilation target.

The "Problem" Is Actually Perfect for ML Infrastructure

Production ML deployment has a challenge that Docker was never designed to solve: TRULY heterogeneous infrastructure.

Your ML pipeline needs to:

Train models on GPU clusters (TensorFlow on CUDA)
Serve inference via Go services (performance-critical paths)
Run client-side inference in browsers (privacy requirements)
Execute on edge devices with 512MB storage (IoT sensors)
Deploy to serverless functions with <100ms cold starts (cost optimization)

Docker solved "works on my machine" by standardizing the machine, and is great for the first one. WASM solves "works across five different machine types" by not privileging any single one.

As wasmCloud CTO Bailey Hayes explained about distributed AI workloads: "Wasm is an excellent compilation target for inferencing-style workloads due to its portable, light weight, open architecture, and near-native speed. Its fast startup time and low resource consumption make it ideal for real-time inferencing on edge devices."

When TensorFlow.js offered a WASM backend, inference performance improved by 10x on CPUs. The WasmEdge runtime enables computer vision models to run on Raspberry Pi devices with sub-10ms inference latency. Cloudflare Workers now serve ML inference requests with zero cold start penalty.

The "identity crisis" is WASM refusing to force you into picking one topology at the expense of all others.

Multi-Language Without the Framework Lock-In

The Component Model is still evolving, which leads to criticism for not being standardized. But it's already solving a problem that no one else is.

Your ML pipeline is not monoglot:

Data scientists prototype in Python (because that's where the models are)
Platform teams serve in Go (because that's what performs at scale)
Performance-critical paths run Rust (because that's what's genuinely fast)
Frontend teams want JavaScript/TypeScript (because that's their skillset)

WASM 3.0's garbage collection support means Java, Kotlin, Scala, OCaml, Dart, and Scheme all now compile to WASM. Not through brittle FFI bridges. Not through "rewrite everything" mandates. They just work.

The Bytecode Alliance documented how this transforms modularity: "Code written in any supported language can now communicate through typed interfaces without relying on foreign function bindings. This transforms modularity from a build-time property into a runtime capability."

For ML pipelines spanning research to production, this flexibility isn't a liability—it's exactly what's needed when your data scientists write Python and your SREs deploy Go.

Even MOAR Security Isolation

Production ML increasingly means running untrusted model code. Fine-tuned models from vendors. Open-source models you didn't train. User-generated model plugins. Custom inference extensions.

With containers, isolation is process-level. You're trusting the container runtime, the kernel, the networking stack. The attack surface spans thousands of packages, each one a potential CVE. It's containable (pardon the pun)! But it is also really easy to footgun yourself.

WASM 3.0's multiple memories feature provides separate address spaces for model weights versus runtime data. When you load untrusted model code, it literally cannot access host memory. The isolation is structural, not procedural.

Fastly's Compute platform runs customer WASM code with mathematical guarantees about what it can access. Fermyon's Spin framework deploys to Akamai's global edge infrastructure with built-in sandboxing. American Express is using WASM for their internal FaaS platform in what could be the largest commercial deployment of WebAssembly to date.

When your inference pipeline spans edge devices, fog nodes, and cloud, your security model can't depend on "trust the entire stack." You need isolation by design.

Docker for Environments, WASM for Computation

This isn't "WASM replaces Docker." That framing misses what each technology actually does well.

Docker standardizes environments. You ship the entire machine: OS, runtime, dependencies, the works. For controlling what code runs against, this remains essential.

WASM standardizes computation. You ship just the logic: algorithms, transformations, inference code. For moving compute to where data lives, this is precisely what's needed.

As Docker's own documentation states: "Docker sees WebAssembly as a complementary technology to Linux containers where developers can choose which technology they use (or both) depending on the use case."

The future isn't Docker OR WASM. It's Docker for environment control, WASM for computational portability.

What This Means for ML Operations

Stop waiting for WASM's "crystallization" into a single use case. Start using it where containers can't reach.

Use WASM for:

Browser inference: Ship 400KB WASM modules instead of 100MB frameworks (transformers.js proves this works at scale)
Edge deployment: Update models in seconds without container rebuilds (WasmEdge on IoT devices)
Multi-language plugins: Let teams use their preferred languages (Component Model enables this today)
Compute-over-data: Move inference to where data lives

Keep using Docker for:

Environment reproducibility (when you need exact dependency matching)
Build environments (when you're building artifacts, not running them)
GPU workloads (when you need specialized hardware access)
Legacy services (when rewriting isn't justified)

The "Docker moment" for WASM may never come. That's fine. We don't need another Docker. We need infrastructure that works across the heterogeneous topology that distributed ML actually requires.

WASM 3.0 provides exactly that. Not by choosing a single identity, but by refusing to.

Further Reading:

Technical Deep Dives:

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.

NOTE: I'm currently writing a book based on what I've seen about the real-world challenges of data preparation for machine learning, focusing on operational, compliance, and cost challenges. I'd love to hear your thoughts!

Originally published at WASM's "Identity Crisis" Is Actually Its Superpower.