The State of WebAssembly in 2026

WebAssembly's original design was deliberately minimal. A Wasm module computes, but it can't read a file, open a socket, print to the terminal, or even tell the time — not without the host environment providing those capabilities explicitly. In 2017 that was a clever browser sandbox. In 2026 it's the foundation for a universal component runtime that runs at the edge, inside databases, on IoT boards, and as the inference backend for in-browser LLMs.

WASI 0.2 Is Boring (in the Best Way)

WASI 0.2 — the first Component-Model-based system interface — has been stable since January 25, 2024. Two and a half years of stable. The right framing in 2026 is no longer "WASI 0.2 just shipped"; it's "WASI 0.2 is the default system interface, and the toolchain has settled."

// A WIT (WebAssembly Interface Types) definition — the contract your component exposes
package wasmhub:image-resizer;
 
interface resize {
  record options {
    width: u32,
    height: u32,
    quality: u8,
  }
 
  resize-jpeg: func(input: list<u8>, opts: options) -> result<list<u8>, string>;
}
 
world image-resizer {
  export resize;
}

With WIT, interfaces are language-agnostic. A Rust component can expose the resize interface above, and a Python host (or a JavaScript host, or another Wasm component) can consume it without hand-written glue code. wit-bindgen 0.58.0 generates the bindings automatically.

WASI 0.3: Async, Ratified 5 Days Ago

The next milestone just landed. WASI 0.3 was ratified on 2026-06-11 by the WASI Subgroup. The headline change is native async support using stream<T> and future<T> as new ABI primitives. Gone is the three-step start-foo / finish-foo / subscribe dance from WASI 0.2 — async functions are now first-class.

wasi:http now has two worlds — wasi:http/service and wasi:http/middleware — that enable in-process service chaining. The Bytecode Alliance claims: "For most microservices this will reduce the time for calling other microservices from milliseconds to nanoseconds: six orders of magnitude."

Wasmtime 45.0.0 (2026-05-21) shipped initial async invocation support in the C API; Wasmtime 46 will turn WASI 0.3 on by default. Jco 1.24.1, released 2026-06-16 (the same day as this post), already supports all of WASI 0.3.

The Component Model Is the Default

In 2025, the Component Model was framed as "shipping in production runtimes." In 2026, it's the default path:

• Wasmtime 45.0.0 is a Bytecode Alliance Core Project and requires Rust 1.93.0 as of May 2026.
• Wasmer 7.x defaults to WASI 0.2 and supports WASIX on top.
• Fermyon Spin 4.0.1 (June 9, 2026) ships manifest v3, with WASI Preview 3 opt-in since Spin 3.5.0.
• Jco 1.24.1 is the canonical JavaScript path — transpile, host, run, and serve WASI components from Node.js and the browser.
• wasmCloud 2.3.0 is CNCF Incubating and ships WASI Preview 3 in wash-runtime, with wasi:tls in production.

The canonical way to build a Rust → WASI component is cargo-component 0.21.1. For JavaScript, it's componentize-js or Jco's transpile flow. For Python, componentize-py 0.24.0. For C# / .NET, componentize-dotnet. A clarifying note: component-model output is cargo-component's job, not wasm-pack's. wasm-pack 0.15.0 (2026-05-15) ships with wasm64-unknown-unknown support, but it produces browser-targeted JS+Wasm bundles via wasm-bindgen. Don't confuse the two.

The registry story shifted too. warg, the original Wasm registry, was archived on 2025-07-28. The community moved to OCI-based wasm-pkg-tools — Wasm components can now publish to Docker Hub, GHCR, AWS ECR, or any OCI-compliant registry.

Major Runtimes in 2026

Wasmtime 45.0.0 (2026-05-21) is the reference implementation. Production users include Akamai, Cosmonic, DFINITY (Internet Computer), Embark Studios, Fastly, Huawei Cloud, Microsoft (AKS WASI node pools), Shopify, and SingleStore. Three release lines run in parallel: v45, v44, v36, v24. Worth noting: wasi-common and wasi-threads are slated for removal in v47.0.0.

Wasmer 7.1.0 (2026-03-27) is the home of WASIX. v7.0.0 introduced green-thread context switching, experimental async, and full dynamic linking; v7.1.0 added N-API support for Edge.js and reproducible builds.

WasmEdge 0.17.0 (2026-05-18) is the AI/edge-leaning runtime. The CNCF page still lists it as Sandbox (since 2021-04-28) — it has not graduated to Incubating. WasmEdge is the only actively maintained runtime shipping WASI-NN with HIP GPU support for llama.cpp, and it integrates with runwasi, the consolidated containerd shim.

wazero 1.12.0 (2026-05-29) is the only mature Go-only runtime — zero CGO, zero dependencies. v1.12.0 added Extended Constant Expressions, Exception Handling, and Typed References, moving it closer to Wasm 3.0. Important caveat: wazero is WASI Preview 1 only.

StarlingMonkey (Mozilla, 0.3.0 in March 2026) is the Bytecode Alliance's standalone Wasm engine embedding SpiderMonkey. It powers Fastly's JS Compute and the Fermyon Spin JS SDK.

Fermyon Spin 4.0.1 (June 9, 2026) is the most production-tracted framework for Wasm-on-serverless. In May 2026, Akamai acquired Fermyon, and the spin repo now lives under github.com/spinframework/spin. Manifest v2 is legacy; use manifest v3.

A few runtimes to avoid for new work in 2026: Wasm3 (no release since 2021-06-02) and Wasm Workers Server (no release since 2023-10-26). Both are stable but dormant. WAMR (WebAssembly Micro Runtime) is the more actively maintained Bytecode Alliance option for embedded.

Browser Support: Wasm GC, Memory64, and Beyond

All major browsers have shipped the Wasm feature set that was "in progress" in 2024-2025. The headline:

• Wasm GC is the most consequential for application developers. Languages with managed memory — Dart 3.5+, Kotlin/Wasm, OCaml 5, Java's experimental "Project Galahad," MoonBit — can now compile to Wasm and use the browser's own GC. The "JS vs Wasm" dichotomy is becoming "JS vs Wasm vs Wasm-GC-languages."
• Memory64 shipped in Chrome 133 (2025) and Safari Technology Preview. The 4GB linear-memory ceiling is gone. wasm-bindgen 0.2.120 (April 2026) added support for the wasm64-unknown-unknown target, and wasm-pack 0.15.0 followed. This unlocks in-browser dataframes, large image stacks, and any workload that needed more than 4GB of working memory.
• Threads + Atomics is universal; SIMD is in every shipping browser; Tail Calls and Exception Handling are GA. The "what's new" table from the 2025 post is now historical record.

Use Cases in 2026

Edge and serverless. The Wasm-on-edge story is mature. Cloudflare Workers runs Wasm via V8 isolates and ships a jco-based component path; Workers AI is GA with 50+ open-source models. Fastly Compute is Wasm-first with per-request isolation. Shopify Functions is one of the strongest public "Wasm in production" stories — every Shopify Function is a Wasm module constrained to 256KB and 5ms of execution time. Fermyon Spin 4.x powers Akamai's developer story post-acquisition. Deno Deploy imports Wasm modules natively since Deno 2.1. Vercel Functions ships an explicit Wasm runtime alongside Node, Bun, and Edge.

AI and ML. Wasm is a credible inference substrate. WasmEdge + WASI-NN + llama.cpp runs LLM inference on edge nodes with HIP GPU support. WebLLM v0.2.83 (April 2026) uses Wasm + WebGPU to run Llama 3, Phi 3, Mistral 7B, and Qwen2 in the browser. Hugging Face Transformers.js defaults to CPU via Wasm and supports 11 NLP, 8 vision, 3 audio, and 5 multimodal tasks. ONNX Runtime Web requires SIMD + threads since v1.19.0. llama.cpp on Wasm (via wllama or llama-cpp-wasm) is the pure-Wasm path for in-browser inference without WebGPU.

Blockchain and smart contracts. CosmWasm 3.0.7 (May 21, 2026) is active and Rust-only — used in production by multiple Cosmos SDK chains (Juno, Secret, Stargaze, Neutron, Injective). The original eWasm initiative for Ethereum, however, was archived on 2026-05-01 — the initiative is no longer being actively maintained in that form.

Databases and extensions. DuckDB Wasm 1.5.3 runs SQL on JSON/Parquet/CSV in the browser, with a 4GB memory cap and single-threaded default. SQLite Wasm is at 3.46+ with OPFS integration. SingleStore ships Wasm UDFs.

Bytecode Alliance: 2025–2026 Milestones

A few dates that frame the last 18 months: 2024-01-25 WASI 0.2 launched. 2025-04-22 Wasmtime LTS releases (2-year security maintenance). 2025-04-30 Wasmtime promoted to the first Bytecode Alliance Core Project. 2025-07-28 warg registry archived. 2025-11-19 Function inliner for Wasmtime/Cranelift. 2026-05-21 Wasmtime 45.0.0 with initial async, copying GC. 2026-06-08 "The Road to Component Model 1.0" published. 2026-06-11 WASI 0.3 ratified.

The Bottom Line

WebAssembly in 2026 is the universal binary format for portable, sandboxed code — in browsers, on edge nodes, inside databases, and increasingly in the LLM inference stack. WASI 0.2 has been the stable default for two and a half years; WASI 0.3 just shipped async as a first-class primitive. The Component Model is no longer "shipping" — it's the default. Memory64 broke the 4GB ceiling in Chrome. Wasm GC made managed-language ports small and fast.

The story from here is the Component Model 1.0 stabilization and the runtimes' incremental adoption of WASI 0.3. For application developers, the practical shift is done: if you're building a plugin system, an edge function, a sandbox for untrusted code, or an in-browser ML pipeline, Wasm is the format you reach for first.