WebAssembly in 2026 - The Complete Guide to WASI, Runtimes, and the Component Model

WebAssembly has grown from a browser compilation target into a universal runtime for browsers, servers, and the edge

WebAssembly in 2026 - The Big Picture

WebAssembly started as a way to run C++ games in the browser. In 2026, it has become something far more ambitious: a universal, sandboxed binary format that runs everywhere from browsers to servers to IoT devices to blockchain smart contracts.

The numbers tell the story. According to the 2026 State of WebAssembly survey, 67% of respondents now use Wasm in production (up from 47% in 2024). Server-side usage has overtaken browser-only usage for the first time, with 52% of production deployments targeting non-browser environments.

Three developments made this possible:

1. WASI Preview 2 stabilized in early 2026, giving Wasm modules a standard way to access files, networking, HTTP, and clocks without a browser
2. The Component Model reached 1.0, enabling modules written in different languages to compose together through typed interfaces
3. Docker shipped native Wasm support, letting developers run Wasm workloads alongside Linux containers using the same toolchain

The result is a technology that is no longer "JavaScript but faster." WebAssembly in 2026 is a portable, secure, polyglot runtime that competes with containers for server workloads and with JavaScript for browser compute. This guide covers every major piece of the ecosystem.

WASI Preview 2 and Preview 3

WASI (WebAssembly System Interface) is the standardized set of APIs that lets Wasm modules interact with the outside world. Think of it as the POSIX of WebAssembly, but designed from scratch with security and portability as first principles.

WASI Preview 2 - The Foundation

WASI Preview 2 (also called WASI 0.2) reached stability in January 2026 after nearly two years of iteration. It replaced the POSIX-like Preview 1 with a completely new architecture built on the Component Model.

The key interfaces in Preview 2:

The critical difference from Preview 1: everything in Preview 2 is capability-based. A Wasm component cannot access the filesystem unless the host explicitly grants it a filesystem capability. This is not an afterthought bolted on top. It is the core design principle.

// A Rust component using wasi:http to handle incoming requests
use wasi::http::types::{IncomingRequest, ResponseOutparam, OutgoingResponse, OutgoingBody};

fn handle(request: IncomingRequest, response_out: ResponseOutparam) {
    let path = request.path_with_query().unwrap_or_default();
    let response = OutgoingResponse::new(200);
    let body = response.body().unwrap();

    let stream = body.write().unwrap();
    stream.blocking_write_and_flush(
        format!("Hello from Wasm! You requested: {path}").as_bytes()
    ).unwrap();

    OutgoingBody::finish(body, None).unwrap();
    ResponseOutparam::set(response_out, Ok(response));
}

WASI Preview 3 - Async Streams and Native Async

Preview 3 is currently in draft and expected to stabilize by late 2026. The headline feature is native async support at the component level.

In Preview 2, async I/O works through a polling mechanism (wasi:io/poll). It works, but it forces every language to implement its own async runtime on top of a fundamentally synchronous execution model. Preview 3 changes this by adding:

• Async streams - first-class readable and writable streams that suspend and resume without polling
• Async functions in WIT - component interfaces can declare functions as async, letting the runtime schedule them cooperatively
• Structured concurrency - components can spawn concurrent tasks with well-defined cancellation and error propagation
• Backpressure - built-in flow control so fast producers do not overwhelm slow consumers

This matters because it means languages like Rust (with tokio), Go (with goroutines), and Python (with asyncio) can map their native async models directly onto Wasm's async primitives instead of shimming everything through synchronous wrappers.

// WIT interface with async functions (Preview 3 draft)
package example:streaming@0.1.0;

interface data-processor {
    // Async function that processes a stream of records
    async process: func(input: stream<record>) -> stream<result>;

    record record {
        id: u64,
        payload: list<u8>,
    }

    variant result {
        ok(processed-record),
        error(string),
    }

    record processed-record {
        id: u64,
        checksum: u64,
    }
}

The Component Model and WIT

If WASI is the "what can Wasm do" layer, the Component Model is the "how do Wasm modules talk to each other" layer. It reached 1.0 in 2026 and it is arguably the most important advancement in the Wasm ecosystem since the MVP spec.

What the Component Model Solves

Core WebAssembly modules are limited. They can only exchange integers and floats. Want to pass a string? You need to manually manage shared linear memory, agree on encoding, handle allocation and deallocation. Want to compose two modules? You need glue code that understands both modules' memory layouts.

The Component Model fixes this by defining:

• A rich type system - strings, lists, records, variants, enums, options, results, flags, and resources
• Interface definitions via WIT (Wasm Interface Type) - a human-readable IDL that describes what a component imports and exports
• Canonical ABI - a standard binary encoding so any language can produce and consume component types without custom serialization
• Composition - components can be wired together at build time or runtime, with one component's exports satisfying another's imports

WIT in Practice

WIT files are the contracts between components. Here is a real-world example of a key-value store interface:

// key-value store interface definition
package myapp:kv@1.0.0;

interface store {
    // A handle to an open bucket
    resource bucket {
        constructor(name: string);
        get: func(key: string) -> option<list<u8>>;
        set: func(key: string, value: list<u8>) -> result<_, error>;
        delete: func(key: string) -> result<_, error>;
        list-keys: func(prefix: string) -> list<string>;
    }

    enum error {
        not-found,
        access-denied,
        storage-full,
        internal,
    }
}

world kv-app {
    import myapp:kv/store@1.0.0;
    export wasi:http/incoming-handler@0.2.0;
}

The power here is that the component importing myapp:kv/store does not care whether the implementation is backed by Redis, DynamoDB, SQLite, or an in-memory hash map. The WIT interface is the contract. The host (or another component) provides the implementation at runtime.

Composing Components

The wasm-tools compose CLI lets you wire components together:

# Build individual components
cargo component build --release -p http-handler
cargo component build --release -p kv-redis

# Compose them: http-handler imports kv/store, kv-redis exports it
wasm-tools compose \
    target/wasm32-wasip2/release/http_handler.wasm \
    --definitions target/wasm32-wasip2/release/kv_redis.wasm \
    -o composed.wasm

# Run the composed component
wasmtime serve composed.wasm

This is the "DLL for the internet" vision that the Wasm community has been working toward. Components are language-agnostic, sandboxed, and composable. A Rust HTTP handler can use a Go authentication middleware and a Python ML inference component, all communicating through typed WIT interfaces with zero serialization overhead.

Wasm in the Browser

WebAssembly's original home is still one of its strongest. Browser Wasm usage continues to grow, driven by applications that need near-native performance without plugins or downloads.

Production Browser Applications

Figma is the poster child for browser Wasm. Their rendering engine, written in C++ and compiled to Wasm, handles complex vector graphics at 60fps. In 2025, Figma reported that their Wasm renderer processes 3x more objects per frame than their previous asm.js implementation, with consistent frame times under 16ms even on mid-range hardware.

Google Earth migrated from Native Client (NaCl) to WebAssembly in 2020 and has continued to optimize. The 2026 version streams terrain data through Wasm-powered decompression that runs 4x faster than the equivalent JavaScript, enabling smooth globe navigation at 4K resolution.

Adobe Photoshop on the web uses Wasm for its compute-intensive filters, layer compositing, and image decoding. Adobe's engineering team reported at Chrome Dev Summit 2025 that their Wasm modules handle 90% of pixel manipulation operations, with the remaining 10% delegated to WebGPU shaders for GPU-accelerated effects.

Other notable browser Wasm deployments in 2026:

• AutoCAD Web - full CAD engine compiled from C++ to Wasm, handling 3D modeling in the browser
• Lichess - Stockfish chess engine running at near-native speed via Wasm with SIMD and threads
• Squoosh - Google's image compression tool using codecs (MozJPEG, WebP, AVIF) compiled to Wasm
• FFmpeg.wasm - full video transcoding in the browser, now supporting hardware-accelerated decoding via WebCodecs bridge
• SQLite Wasm - the official SQLite team ships a Wasm build that powers offline-first web apps with the Origin Private File System (OPFS) backend

Browser Wasm Features in 2026

The browser Wasm spec has evolved significantly beyond the 2017 MVP:

The GC proposal deserves special attention. Before Wasm GC, languages like Java and Kotlin had to ship their entire garbage collector inside the Wasm binary, adding 2-5MB of overhead. With Wasm GC, these languages use the browser's built-in GC, producing binaries that are 5-10x smaller. Kotlin/Wasm binaries dropped from ~8MB to under 800KB.

Server-Side Runtimes

Server-side Wasm is where the most explosive growth is happening. The pitch is compelling: run sandboxed, portable code with near-native performance, sub-millisecond cold starts, and a fraction of the memory footprint of containers.

Wasmtime

Wasmtime is the reference runtime from the Bytecode Alliance (backed by Fastly, Intel, Microsoft, and others). It is the most spec-compliant runtime and the first to implement WASI Preview 2 fully.

• Version: 20.x (May 2026)
• Compilation: Cranelift compiler backend, AOT and JIT modes
• Performance: Within 5-15% of native for compute workloads
• Component Model: Full support including composition and resources
• Embedding: Rust, C, C++, Python, Go, .NET, Ruby host APIs
• Production users: Fastly Compute, Fermyon Spin, wasmCloud, Shopify Functions

# Install wasmtime
curl https://wasmtime.dev/install.sh -sSf | bash

# Run a WASI component
wasmtime run my-component.wasm

# Serve an HTTP component
wasmtime serve --addr 0.0.0.0:8080 my-http-handler.wasm

# AOT compile for faster startup
wasmtime compile my-component.wasm -o my-component.cwasm
wasmtime run my-component.cwasm

WasmEdge

WasmEdge is a CNCF Sandbox project optimized for edge and AI inference workloads. It stands out for its LLVM-based AOT compiler and native AI framework integrations.

• Unique features: Native TensorFlow/PyTorch inference, WASI-NN for ML, built-in HTTP server
• Performance: AOT mode achieves near-native speed, often faster than Wasmtime for specific workloads
• Kubernetes: First-class integration via containerd shim and CRI-O
• Production users: Flows.network, Second State, several automotive OEMs for in-vehicle computing

Wasmer

Wasmer focuses on developer experience and the package ecosystem. Their WAPM registry hosts thousands of pre-compiled Wasm packages.

• Compiler backends: Singlepass (fast compile), Cranelift (balanced), LLVM (max performance)
• Wasmer Edge: Their managed edge platform for deploying Wasm applications globally
• Language SDKs: Embed Wasmer in Rust, C/C++, Python, Go, PHP, Ruby, Java, JavaScript
• Unique feature: wasmer run can execute packages directly from the registry without pre-downloading

Fermyon Spin 3.0

Spin is a framework for building and running Wasm microservices. Spin 3.0, released in Q1 2026, brought major improvements:

• Component dependencies - import and compose components from registries directly in spin.toml
• Spin Factors - a modular host architecture where capabilities (key-value, SQLite, LLM inference) are pluggable
• SpinKube 1.0 - run Spin apps on Kubernetes via the spin-operator and containerd-shim-spin
• Fermyon Cloud - managed hosting with sub-millisecond cold starts and automatic scaling to zero

# spin.toml - Spin 3.0 application manifest
spin_manifest_version = 2

[application]
name = "my-api"
version = "1.0.0"

[[trigger.http]]
route = "/api/..."
component = "api-handler"

[component.api-handler]
source = "target/wasm32-wasip2/release/api_handler.wasm"
allowed_outbound_hosts = ["https://api.example.com"]

[component.api-handler.key_value_stores]
default = "default"

[component.api-handler.sqlite_databases]
default = { path = "data.db" }

wasmCloud v2

wasmCloud is a CNCF project that takes a different approach: it separates business logic (Wasm components) from infrastructure capabilities (providers) using a distributed lattice.

wasmCloud v2, released in late 2025, rebuilt the platform entirely on the Component Model:

• Declarative deployments via wadm (Wasm Application Deployment Manager)
• Distributed by default - components communicate over NATS, can span multiple hosts and clouds
• Hot-swappable providers - switch from Redis to DynamoDB without recompiling your component
• WIT-first development - define your interfaces in WIT, implement in any language
• Wash CLI - developer tooling for building, testing, and deploying wasmCloud applications

Language Support

WebAssembly is language-agnostic by design, but the quality of toolchain support varies dramatically. Here is where every major language stands in 2026.

Rust - First-Class Citizen

Rust has the best Wasm story of any language. Period. The wasm32-wasip2 target is a tier-2 supported platform in rustc, meaning it ships with every Rust release and is tested in CI.

# Add the WASI Preview 2 target
rustup target add wasm32-wasip2

# Build a component with cargo-component
cargo install cargo-component
cargo component new my-service --lib
cargo component build --release

The cargo-component tool handles WIT binding generation, component packaging, and registry publishing. Rust's ownership model maps naturally to Wasm's linear memory, producing compact binaries (a typical HTTP handler compiles to 2-4MB). The wit-bindgen crate generates idiomatic Rust types from WIT interfaces.

Rust is the default choice for performance-critical Wasm components, plugin systems, and any project where binary size and execution speed matter.

Go

Go's Wasm support improved significantly with Go 1.23 (August 2025), which added the wasip2 GOOS target:

# Build a Go program for WASI Preview 2
GOOS=wasip2 GOARCH=wasm go build -o main.wasm ./cmd/server

The main trade-off is binary size. Go's runtime, garbage collector, and goroutine scheduler all get compiled into the Wasm binary, producing modules in the 8-15MB range. The TinyGo compiler produces much smaller binaries (500KB-2MB) by using a simpler runtime, but it does not support all Go standard library packages.

Go is a solid choice for teams already invested in the Go ecosystem who want to target Wasm without learning Rust. The goroutine model works well with WASI Preview 2's async I/O, and the standard library's HTTP package maps cleanly to wasi:http.

C and C++

C and C++ were the first languages to target Wasm via Emscripten (for browser) and wasi-sdk (for WASI). In 2026, the toolchain is mature:

• Emscripten - compiles C/C++ to Wasm + JS glue for browser deployment. Powers Figma, Google Earth, AutoCAD Web
• wasi-sdk - Clang/LLVM-based toolchain targeting WASI. Produces standalone Wasm modules without browser dependencies
• wasi-libc - a WASI-compatible C standard library based on musl
• Component Model support - via wit-bindgen C bindings and the componentize tool

C/C++ remains the go-to for porting existing codebases to Wasm. If you have a million-line C++ codebase, Emscripten or wasi-sdk is your path to Wasm.

Python and Pyodide

Pyodide compiles CPython to Wasm, bringing the entire Python ecosystem (including NumPy, Pandas, scikit-learn) to the browser. In 2026, Pyodide 0.27 supports Python 3.13 and includes over 200 pre-built packages.

For server-side WASI, the story is newer. The componentize-py tool can compile Python scripts into Wasm components, though with significant limitations: startup is slower (100-300ms), memory usage is higher, and not all C extensions work. It is best suited for glue code, scripting, and ML inference pipelines where Python's ecosystem outweighs the performance cost.

# Create a Python Wasm component
pip install componentize-py
componentize-py -d my-world.wit -w my-world componentize app -o my-component.wasm

.NET and Blazor

Microsoft's Blazor WebAssembly lets C# developers build interactive web UIs that run entirely in the browser. .NET 9 (November 2025) brought major Wasm improvements:

• Blazor Wasm AOT - ahead-of-time compilation produces 2-3x faster execution than the interpreted mode
• Trimming improvements - aggressive tree-shaking reduced typical Blazor app download size from 15MB to 4-6MB
• WASI experimental workload - dotnet workload install wasi-experimental enables building WASI Preview 2 components from C#
• NativeAOT for Wasm - in preview, compiles C# directly to Wasm without the .NET runtime, producing sub-1MB binaries

Blazor is the strongest option for enterprise teams with existing .NET skills who want to build web applications without JavaScript. The WASI workload is still experimental but progressing quickly.

Other Languages

Docker + Wasm

Solomon Hykes, Docker's co-founder, famously tweeted in 2019: "If WASM+WASI existed in 2008, we wouldn't have needed to create Docker." In 2026, Docker and Wasm are not competitors. They are collaborators.

The containerd-wasm-shim

Docker Desktop has supported Wasm workloads since 2022 via the containerd-wasm-shim. In 2026, this support is GA and production-ready:

# Dockerfile for a Wasm workload
FROM scratch
COPY target/wasm32-wasip2/release/my_app.wasm /app.wasm
ENTRYPOINT ["/app.wasm"]

# Build and run with Docker
docker buildx build --platform wasi/wasm -t my-wasm-app .
docker run --runtime=io.containerd.wasmtime.v2 --platform wasi/wasm my-wasm-app

The shim architecture supports multiple Wasm runtimes as containerd plugins:

• io.containerd.wasmtime.v2 - Wasmtime (default, most compatible)
• io.containerd.wasmedge.v2 - WasmEdge (best for AI workloads)
• io.containerd.wasmer.v2 - Wasmer
• io.containerd.spin.v2 - Fermyon Spin (for Spin applications)

Why Run Wasm in Docker

The question is fair: if Wasm is supposed to replace containers, why run it inside Docker? The answer is operational consistency.

• Same CI/CD pipeline - build, tag, push, and deploy Wasm images using the same Docker/OCI toolchain your team already knows
• Same orchestration - Kubernetes, Docker Compose, and ECS can schedule Wasm workloads alongside Linux containers
• Same registries - push Wasm images to Docker Hub, ECR, GCR, or any OCI-compliant registry
• Gradual migration - replace individual microservices with Wasm components without rearchitecting your entire platform

# docker-compose.yml mixing Linux containers and Wasm
services:
  postgres:
    image: postgres:16
    ports:
      - "5432:5432"

  api:
    image: my-wasm-api:latest
    runtime: io.containerd.wasmtime.v2
    platform: wasi/wasm
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://postgres:5432/mydb

  frontend:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./dist:/usr/share/nginx/html

Edge Computing

Edge computing is where Wasm's advantages over containers are most dramatic. When your code runs in 300+ locations worldwide and needs to cold-start in under a millisecond, containers simply cannot compete.

Cloudflare Workers

Cloudflare Workers was one of the first platforms to bet on Wasm at the edge. In 2026, Workers runs across 330+ data centers and handles trillions of requests per month.

• Runtime: V8 isolates with Wasm support (not a standalone Wasm runtime)
• Cold start: Under 5ms for Wasm modules, often under 1ms
• Languages: Rust, C/C++, Go, Python (via Pyodide), and any language that compiles to Wasm
• Integrations: Workers KV, Durable Objects, R2 (S3-compatible storage), D1 (SQLite), Queues, AI inference
• Pricing: Free tier includes 100K requests/day. Paid starts at $5/month for 10M requests

// Cloudflare Worker in Rust (using worker-rs)
use worker::*;

#[event(fetch)]
async fn fetch(req: Request, env: Env, _ctx: Context) -> Result<Response> {
    let router = Router::new();

    router
        .get_async("/api/data/:id", |_req, ctx| async move {
            let id = ctx.param("id").unwrap();
            let kv = ctx.kv("MY_KV")?;

            match kv.get(id).text().await? {
                Some(value) => Response::ok(value),
                None => Response::error("Not found", 404),
            }
        })
        .run(req, env)
        .await
}

Fastly Compute

Fastly Compute (formerly Compute@Edge) runs Wasm natively on Wasmtime. Unlike Cloudflare's V8-based approach, Fastly compiles Wasm modules ahead of time for maximum performance.

• Runtime: Wasmtime with Cranelift AOT compilation
• Cold start: Under 50 microseconds (yes, microseconds) for AOT-compiled modules
• WASI support: Full WASI Preview 2 with Component Model
• Unique features: Geolocation API, edge dictionaries, real-time log streaming, Fanout for WebSocket/SSE
• Production users: The New York Times, Stripe, GitHub, Shopify

Other Edge Platforms

• Vercel Edge Functions - V8-based, supports Wasm modules alongside JavaScript/TypeScript
• Deno Deploy - V8-based, first-class Wasm support with Deno's permission model
• Netlify Edge Functions - Deno-based, Wasm modules via import
• Akamai EdgeWorkers - V8-based, Wasm support for compute-intensive tasks at the CDN edge
• AWS Lambda@Edge - not Wasm-native, but Wasm modules can run inside Node.js/Python Lambda functions

Performance Benchmarks

Performance claims are easy to make and hard to verify. Here are real, reproducible benchmarks from 2026 comparing Wasm to containers and native execution across multiple dimensions.

Cold Start Latency

Cold start is where Wasm dominates most dramatically. These numbers come from Fermyon's 2026 benchmark suite and independent testing by the CNCF Wasm Working Group:

The 100-1000x faster cold start claim is real and reproducible. Wasm modules do not need to boot an OS, initialize a container runtime, or set up a network namespace. They load a pre-compiled binary into a sandboxed memory space and start executing.

Memory Density

Memory density measures how many instances you can run on a single host. This directly impacts infrastructure costs:

On a 64GB host, you can run roughly 1,400 container instances of a REST API or roughly 18,000 Wasm instances of the same service. At scale, this translates to 85% cost savings on compute infrastructure for workloads that fit the Wasm model.

Execution Speed

For raw compute, Wasm is not as fast as native code, but it is close:

• Compute-bound (Fibonacci, sorting, hashing): Wasm runs at 70-95% of native speed depending on the runtime and workload
• I/O-bound (HTTP handling, database queries): Wasm overhead is negligible (under 5%) because most time is spent waiting on I/O
• SIMD workloads (image processing, ML): Wasm SIMD achieves 80-90% of native SIMD performance
• vs JavaScript: Wasm is 2-10x faster for compute-heavy tasks, roughly equivalent for I/O-heavy tasks

# Benchmark: SHA-256 hashing 1GB of data
# Native (Rust):     1.82s
# Wasm (Wasmtime):   2.04s  (1.12x slower)
# Wasm (WasmEdge):   1.97s  (1.08x slower)
# Node.js (crypto):  3.41s  (1.87x slower)
# Python (hashlib):  4.92s  (2.70x slower)

# Benchmark: JSON parse + transform (10K records)
# Native (Rust):     12ms
# Wasm (Wasmtime):   14ms   (1.17x slower)
# Node.js:           28ms   (2.33x slower)
# Python:            89ms   (7.42x slower)

Cost Analysis

The 85% cost savings figure comes from combining three factors:

1. Memory density (20x) - run 20x more instances per host, reducing the number of hosts needed
2. Cold start elimination - no need to keep warm instances running, enabling true scale-to-zero
3. Smaller images - less storage, faster pulls, less network transfer

A real-world example from Fermyon's case studies: a fintech company migrated 12 microservices from Kubernetes (EKS) to Spin on Fermyon Cloud. Their monthly compute bill dropped from $14,200 to $2,130, an 85% reduction. The services handled the same traffic (2.3M requests/day) with lower p99 latency.

Wasm vs Containers Decision Matrix

Wasm is not a universal container replacement. It excels in specific scenarios and falls short in others. Use this matrix to decide which technology fits your workload.

Choose Wasm When

• You need sub-millisecond cold starts (edge computing, serverless, event-driven)
• You want true scale-to-zero without warm instance costs
• You are building a plugin or extension system and need sandboxed third-party code execution
• You need to run the same binary on Linux, macOS, Windows, and embedded devices
• Memory density matters (multi-tenant SaaS, high-density edge nodes)
• Your workload is short-lived, stateless, and fits within WASI's capability model

Choose Containers When

• You need full OS-level access (system calls, device drivers, kernel modules)
• Your application requires GPU compute (ML training, video rendering)
• You have complex native dependencies that do not compile to Wasm
• You need mature debugging, profiling, and observability tooling
• Your team's existing infrastructure and expertise is container-based
• You are running long-lived services (databases, message brokers, stateful applications)

WASI Interfaces Deep Dive

Beyond the core Preview 2 interfaces, the WASI ecosystem includes a growing set of domain-specific interfaces. These are at various stages of standardization:

Stable Interfaces (WASI 0.2)

• wasi:cli - command-line environment (args, env, stdin/stdout/stderr, exit)
• wasi:clocks - wall clock, monotonic clock for timing and scheduling
• wasi:filesystem - file and directory operations with capability-based access
• wasi:http - incoming and outgoing HTTP with streaming request/response bodies
• wasi:io - pollable streams, the foundation for all async I/O
• wasi:random - cryptographically secure random number generation
• wasi:sockets - TCP and UDP networking

Proposed Interfaces (In Progress)

The WASI proposal process follows a phased model similar to TC39 (JavaScript). Phase 0 is a strawperson proposal, Phase 1 has a champion and initial spec, Phase 2 has a working implementation, Phase 3 is feature-complete with multiple implementations, and Phase 4 is standardized and included in a WASI release.

The most impactful upcoming interface is wasi:observe. Today, observability in Wasm is a pain point. Components cannot emit traces or metrics through a standard interface, forcing each runtime to implement its own solution. wasi:observe will bring OpenTelemetry-compatible observability to every Wasm component, regardless of runtime.

What is Next for WebAssembly

The Wasm ecosystem is moving fast. Here are the most important developments to watch in the second half of 2026 and into 2027:

WASI Preview 3 Stabilization

Preview 3's native async support is the most anticipated feature. Once stable, it will unlock efficient streaming workloads, WebSocket handling, and long-polling patterns that are awkward with Preview 2's polling model. Target: late 2026 or early 2027.

Wasm GC Ecosystem Growth

With Wasm GC shipped in Chrome and Firefox, expect Kotlin/Wasm, Dart/Wasm, and Java/Wasm to gain significant traction. The ability to use the browser's GC instead of shipping one in the binary is a game-changer for managed languages. Flutter Web's Wasm renderer (using Wasm GC) already shows 2x rendering performance over the JavaScript renderer.

Memory64 Standardization

The Memory64 proposal breaks Wasm's 4GB memory limit, enabling workloads like large dataset processing, in-memory databases, and scientific computing. It is in origin trial in Chrome and expected to ship in all browsers by late 2026.

Stack Switching

The stack switching proposal enables efficient coroutines, green threads, and effect handlers in Wasm. This is critical for languages like Go (goroutines), Kotlin (coroutines), and any language with async/await. It is in Phase 3 of the Wasm CG proposal process.

The "Wasm Everywhere" Trajectory

The pattern is clear: Wasm is becoming the universal plugin format. Envoy Proxy uses Wasm for custom filters. Kubernetes uses Wasm for admission webhooks via Kubewarden. Databases like SingleStore and Redpanda use Wasm for user-defined functions. Game engines use Wasm for modding. The Component Model makes this practical by providing a standard, safe, composable extension mechanism.

Five years from now, Wasm will not replace containers or JavaScript. It will be the third pillar of computing alongside them: containers for infrastructure, JavaScript for UI, and Wasm for portable, sandboxed compute that runs everywhere.