Quick Takeaways
What you'll learn in this article
- 1
WebAssembly has evolved from a browser technology to a cloud computing platform
- 2
This guide covers WASI 0
- 3
2 and the Component Model, Akamai's acquisition of Fermyon, Wasm runtimes (Wasmtime, Wasmer, WasmEdge), Wasm 3
Keep reading for detailed implementation, code examples, and real-world results
Updated (February 2026): Complete rewrite replacing generic overview with current WebAssembly ecosystem coverage including WASI 0.2 and the Component Model, Akamai's acquisition of Fermyon, Wasm 3.0 standard with GC and Memory64, runtime benchmarks, Docker and Kubernetes integration via SpinKube, language support across the Component Model, and production deployment data from Cloudflare, Fastly, and Akamai.
WebAssembly Left the Browser
WebAssembly started as a compilation target for running C++ and Rust in web browsers. That was 2017. In 2026, Wasm is a cloud computing platform.
Cloudflare processes billions of daily edge invocations through Wasm. Fastly runs 100,000+ Wasm isolates per CPU core. Akamai acquired Fermyon and deployed Wasm functions across 4,400+ edge locations handling 75 million requests per second. Google migrated its Sheets calculation engine to WasmGC, running 2x faster than the previous JavaScript implementation. Microsoft built Hyperlight Wasm โ micro-VMs that start in 1-2 milliseconds โ and donated it to the CNCF.
The numbers that matter: sub-millisecond cold starts. 95 percent of native execution speed. Binaries 30x smaller than containers. 40 percent less memory. These are not benchmarks from a proof of concept โ they are production metrics from the world's largest infrastructure providers.
Wasm Website Adoption
4.5%
Of Chrome-visited websites use WebAssembly (2025), up 28% year-over-year. 41% of Wasm developers report production usage.
WASI and the Component Model
WASI (WebAssembly System Interface) is what makes server-side Wasm possible. It provides standardized interfaces for Wasm modules to interact with the host system โ filesystem, networking, HTTP, clocks, random numbers โ without breaking the sandbox model.
WASI 0.2: The Current Standard
WASI 0.2, released January 2024, introduced the Component Model โ a fundamental redesign of how Wasm modules are packaged, linked, and composed. Instead of monolithic binaries, the Component Model defines components with explicit interfaces (described in WIT โ WebAssembly Interface Type files) that can be composed into applications regardless of the source language.
Key interfaces in WASI 0.2: wasi-cli (command-line programs), wasi-http (HTTP request/response handling), wasi-sockets (TCP/UDP), wasi-filesystem, wasi-random, and wasi-clocks. The design is modular โ runtimes implement only the interfaces they need. An edge platform might support HTTP but not filesystem access.
WASI 0.3: Native Async
WASI 0.3, with previews available in Wasmtime 37+, adds native async support to the Component Model with explicit stream<T> and future<T> types. This enables any component-level function to be implemented and called asynchronously โ critical for I/O-heavy server workloads. Expected completion around February 2026.
WASI 1.0: The Stability Target
WASI 1.0 โ the first fully stable, non-preview release โ is expected in late 2026 or early 2027. Once shipped, it will provide the stable API surface that enterprise adoption requires. As The New Stack put it: "You won't know when WebAssembly is everywhere in 2026."
Wasm Runtimes
Four runtimes dominate the server-side Wasm landscape, each optimized for different use cases.
Wasmtime (Bytecode Alliance) is the reference implementation and the first runtime to earn Bytecode Alliance Core Project status. Monthly releases have reached version 41+, with an LTS channel providing 2-year security support. Wasmtime 37 added full exception handling, experimental WASI 0.3 async I/O, and Linux PAGEMAP_SCAN support for faster serverless instantiation. Wasmtime leads in cold start performance among JIT/AOT compilers.
Wasmer reached version 6.0 in 2025 with 30-50 percent speedups, achieving roughly 95 percent of native speed on Coremark (up from 90 percent in v5). The LLVM backend reaches within 5 percent of native. Key innovations include zero-cost WebAssembly exceptions (3-4x faster PHP execution) and unified compiler backends where LLVM, V8, and WAMR can run in the same binary.
WasmEdge (CNCF Sandbox) uses an LLVM-based AOT compiler optimized for cloud-native, edge, and IoT workloads. Extensions for network sockets, database drivers (Postgres, MySQL), and AI inference (WASI-NN) make it the strongest fit for edge AI applications.
V8 (Google) powers Cloudflare Workers and all browser Wasm execution. V8 isolates provide essentially zero cold-start overhead with thousands of isolates per process, though V8 is a general JavaScript/Wasm engine rather than a standalone server-side runtime.
Wasm Runtime Selection
Wasmtime
Wasmer
Fermyon, Akamai, and Production Edge Wasm
In December 2025, Akamai acquired Fermyon โ the company behind the Spin framework โ signaling major CDN industry investment in Wasm as the edge execution model.
Fermyon Wasm Functions
Fermyon Wasm Functions went generally available on Akamai's platform in November 2025 with production-validated metrics: 75 million requests per second across edge and cloud, sub-millisecond cold starts (under 0.5ms), and 99.9 percent reliability guarantees. The platform runs across Akamai's 4,400+ edge locations.
Real-world deployments include bot mitigation, URL redirection handling hundreds of thousands of URLs within 1 millisecond, response body manipulation, sub-100ms time-to-first-byte for live streaming, and SEO/AI bot customization.
Spin 3.0
Spin 3.0 (November 2024) introduced component dependencies for true polyglot applications โ build components in Rust, JavaScript, Go, and Python, store them in OCI registries, and compose them into unified applications. Selective deployments let you build a single app and deploy it as distributed microservices across Kubernetes, data centers, and edge locations.
Spin joined the CNCF Sandbox in January 2025, with SpinKube as a subproject. Akamai committed to maintaining all open-source projects post-acquisition.
Wasm 3.0: The Biggest Browser Update
Wasm 3.0 became the W3C standard in September 2025 โ the largest update since WebAssembly's inception, with features that were 6-8 years in development.
Garbage Collection (WasmGC) adds native GC with struct and array types, eliminating the need to bundle language-specific garbage collectors in Wasm binaries. Google Sheets runs 2x faster with WasmGC versus JavaScript. This unlocks efficient Wasm compilation for managed languages like Kotlin, Dart, Java, and C#.
Memory64 expands the address space from 4 GB to 16 exabytes using i64 address types for memories and tables.
Exception Handling provides native throw/try-catch structures with exception tags and payloads, replacing the previous costly JavaScript interop for error handling.
Relaxed SIMD adds implementation-dependent SIMD variants for hardware-specific optimizations on top of the fixed-width SIMD from Wasm 2.0.
Multiple Memories allows a single module to declare multiple memory regions and copy data between them.
All features shipped across Chrome, Firefox, Safari, and Edge.
Docker and Kubernetes Integration
Docker + Wasm
Docker Desktop supports running Wasm workloads side-by-side with traditional Linux containers from the same docker-compose.yml. The integration uses containerd shims via the runwasi library, supporting Wasmtime, Spin, WasmEdge, and Wasmer runtimes.
Wasm modules are packaged as OCI artifacts, and a runtime flag tells Docker to use a Wasm shim instead of the standard Linux runtime. Docker's position: Wasm complements containers rather than replacing them.
The performance caveat: containerizing Wasm adds roughly 143x startup overhead versus standalone Wasm VMs due to standard container lifecycle management. The value is unified tooling and orchestration, not raw performance.
SpinKube: Wasm on Kubernetes
SpinKube is the open-source, Kubernetes-native project for deploying Wasm workloads, combining the Spin operator, containerd-shim-spin, and runtime class manager. Contributors include Microsoft, SUSE, Liquid Reply, and Fermyon. SpinKube is now a CNCF Sandbox subproject under Spin.
SpinKube enables scale-from-zero with minimal latency on any standard Kubernetes cluster โ EKS, AKS, GKE, or k3s. Microsoft closed its experimental WASI node pools in AKS (January 2025) and recommends SpinKube as the replacement.
In April 2025, Fermyon demonstrated serverless hyperscaling with WebAssembly on Google Kubernetes Engine, validating Wasm workloads alongside container workloads in production Kubernetes environments.
Wasm vs Container Performance (Lower is Better)
| metric | wasm | container |
|---|---|---|
| Cold start (ms) | 0.5 | 500 |
| Binary size (MB) | 3 | 80 |
| Memory (relative) | 60 | 100 |
Language Support Across the Component Model
The Component Model makes Wasm truly polyglot โ components built in different languages compose into applications through shared WIT interfaces.
Production-Ready
Rust has the best Wasm support in the ecosystem. The cargo-component plugin generates Component Model binaries directly. Rust is the frontrunner for WASI 0.2 component development.
C/C++ has mature support via Emscripten (browser) and the WASI SDK (server-side). The longest-standing Wasm compilation target.
C# / .NET through Blazor WebAssembly (.NET 9) delivers 25 percent faster startup and 40 percent smaller AOT payloads versus 2023, with WASM SIMD support.
Go via TinyGo 0.34.0+ has native Component Model and WASI 0.2 support. Standard Go has a wasip1 target; WASI P2 support is expected in a future Go release.
Rapidly Maturing
JavaScript/TypeScript works through StarlingMonkey and Javy. Spin supports JS/TS components natively.
Python compiles to Wasm via Pyodide (CPython on Emscripten) for browsers and componentize-py for WASI Component Model targets. Cloudflare uses Wasm memory snapshots to cut Python cold starts from 10 seconds to under 1 second.
Kotlin/Wasm reached beta in Kotlin 2.2.20 (September 2025), with Compose Multiplatform outperforming JavaScript. Full stability expected late 2026.
Swift 6.1 (2025) made Wasm a tier-one compilation target โ the first official release with mainline toolchain support for WebAssembly.
Wasm for AI and ML
WASI-NN provides a standard interface for neural network inference in Wasm, abstracting ML framework backends (TensorFlow, ONNX, OpenVINO, PyTorch) behind a common API. WasmEdge implements WASI-NN with production-ready ONNX and OpenVINO backends.
ONNX Runtime Web runs ML models in browsers with WebGPU, WebGL, WebNN, and WebAssembly backends. WebGPU support launched in ONNX Runtime 1.17, enabling models like Stable Diffusion Turbo entirely in-browser. Quantized models (INT4, INT8, FP16) make billion-parameter LLMs viable in browser environments.
Fermyon Wasm Functions on Akamai provide AI inference with GPU acceleration at 4,400+ edge locations. Spin includes built-in AI inference integrations. Wasm's portable, lightweight architecture makes it particularly suited for real-time inference on edge devices where container overhead is prohibitive.
WebAssembly Production Use Cases by Category (Estimated, 2026)
| Name | Value |
|---|---|
| Edge serverless (Cloudflare, Fastly, Akamai) | 35 |
| Browser applications (Figma, Sheets, Zoom) | 30 |
| Plugin/extension systems (Shopify, Envoy) | 15 |
| Kubernetes workloads (SpinKube) | 10 |
| AI/ML inference (WASI-NN, edge) | 10 |
Production Deployments
Beyond the edge platforms already covered, Wasm powers critical infrastructure across major technology companies.
Google migrated the Sheets calculation engine to WasmGC (2x faster). Meet uses Wasm for real-time video processing. GKE Dataplane supports Wasm workloads.
Figma compiles its C++ rendering engine to Wasm, achieving 3x load time improvement โ one of the earliest and most visible Wasm production deployments.
Zoom uses SIMD-optimized Wasm for audio/video codecs and image processing.
Shopify built its plugin and extension system on WebAssembly for secure, sandboxed third-party code execution.
Microsoft developed Hyperlight Wasm โ micro-VMs wrapping each Wasm workload in a hypervisor-backed sandbox with no kernel or OS. Startup takes 1-2 milliseconds per VM and Wasmtime application, targeting sub-millisecond. Hyperlight was donated to the CNCF Sandbox and powers Azure Front Door Edge Actions (private preview).
Wasm vs Containers for Cloud Workloads
WebAssembly
Linux Containers
Browser Foundation
WebAssembly 1.0 ships across all major browsers. Rust becomes the primary Wasm compilation language. Figma demonstrates production Wasm with 3x load time improvement. WASI proposal begins.
Server-Side Emergence
Cloudflare Workers and Fastly Compute prove Wasm at edge scale. Fermyon launches Spin. Docker announces Wasm support. WasmEdge enters CNCF. The "Wasm beyond the browser" narrative takes hold.
Standards Mature
WASI 0.2 and the Component Model ship. WasmGC lands in browsers. SpinKube brings Wasm to Kubernetes. wasmCloud reaches CNCF incubating status. Spin 3.0 enables polyglot component composition.
Platform Scale
Wasm 3.0 becomes W3C standard. Akamai acquires Fermyon for edge Wasm at 75M RPS. Spin and Hyperlight Wasm join CNCF. WASI 0.3 adds native async. Swift and Kotlin add tier-one Wasm targets. Wasm becomes standard cloud infrastructure.
WebAssembly has completed its transition from browser technology to cloud infrastructure. The standards are stable (WASI 0.2, Component Model, Wasm 3.0). The runtimes are fast (95 percent of native, sub-millisecond cold starts). The platforms are production-proven (Cloudflare, Fastly, Akamai processing billions of daily requests). The language ecosystem spans from Rust and C++ through Go, Python, Kotlin, and Swift. For engineering teams evaluating Wasm, the question has shifted from "is it ready?" to "which workloads benefit most from the portability, speed, and density advantages?"

