✍️ 필사 모드: WASM Ecosystem 2026 — Wasmtime, Wasmer, WasmEdge, Spin, Component Model, Extism Deep Dive (The Universal Execution Layer Beyond the Browser)

Prologue — Promise from 2008, Invoice in 2026

When WebAssembly 1.0 MVP shipped in browsers in 2017, two promises came with it. "You can run C/C++/Rust in browsers at near-native speed." And "someday this will also run outside the browser." Nine years passed. The first promise was already proven by Figma, AutoCAD Web, and Photoshop Web. The second — honestly — only started really working after WASI 0.2 was finalized in January 2024.

It is May 2026. WASM is already running production we do not even notice. Parts of Cloudflare Workers run on Wasmtime rather than V8 isolates, Shopify Functions compiles merchant-uploaded Rust/JS into WASM and runs it at the edge, and Fastly Compute has been Wasmtime-based from day one. AWS Lambda is exploring WASM for some workloads via SnapStart, and Azure Container Apps officially supports WASM workloads through SpinKube. The line "WASM is the next thing after containers" is no longer a slide promise — it is a billing unit on the cloud invoice.

This post draws the WASM ecosystem map as of May 2026 in one shot. Four runtimes (Wasmtime, Wasmer, WasmEdge, Spin), the standards (WASI 0.2/0.3, Component Model, WAC), the tools (Jco, Extism, wasm-tools, Wash), the languages (Wing, Kotlin/WASM, Dart/WASM), and real production cases. Which tool to pick when, why the Component Model is the big shift, and who is using it in Korea and Japan.

1. WASM in 2026 — Where We Stand

One-line summary first. WASM grew up from a browser accelerator into a "universal execution layer." The phrase sounds grand but the meaning is simple — the same .wasm binary runs in browsers, servers, edges, embedded devices, and plugin hosts. The promise of "build once, run everywhere" finally became real.

Coordinates as of 2026.

Three core insights.

First, the Component Model is the biggest change. WASM 1.0 in 2017 only defined "core modules." Core modules only know i32, i64, f32, f64, memory, and tables. They cannot pass strings. So whenever a host and guest needed to exchange strings, they had to negotiate an ABI ("read N bytes starting at memory address X"). The Component Model standardizes that ABI. A module written in Rust can be called from Python, Go, or JS hosts without per-language glue. And this really started working in January 2024.

Second, runtimes consolidated into a Big Four. What were more than 10 runtimes in 2020 collapsed into effectively four. Wasmtime from Bytecode Alliance (standards), Wasmer (commercial + registry), WasmEdge (CNCF, edge), Spin (serverless platform). The rest are embedded-specialized (WAMR, wasm3) or stalled.

Third, WASM in 2026 is at the "use it" stage, not the "wait for it" stage. Until 2022 the question was "when will it be production-ready." In 2026 the question is "which tool for which workload." Even if your team is not using it, another team in your company likely is.

2. WASI 0.2 Component Model (2024.01) — Why This Is a Big Change

One-line definition of the Component Model — a language-independent calling convention + interface definition language (IDL) + type system. Roughly what gRPC did to inter-service RPC with Protobuf, the Component Model does to inter-module calls in WASM.

Start with the limits of core WASM. Core modules only know these types:

i32, i64, f32, f64, v128, funcref, externref

Strings, structs, optional types, result types — none of them. So whenever a Rust module needed to return a string to a JS host, both sides had to redesign "read N UTF-8 bytes from memory address X." wasm-bindgen automated this, but only for JS.

What the Component Model introduces — four pieces.

1. WIT (Wasm Interface Type) — the IDL. You declare interfaces in .wit files using high-level types: record, variant, option, result, list, string.
2. Canonical ABI — a standard ABI defining how WIT types map down to core WASM i32/i64 and memory layouts. Every language follows the same convention.
3. Component — a unit bundling a core module + WIT interface + import/export spec. It is still a .wasm file but with a different header (layer 1 = module, layer 2 = component).
4. WASI standard interfaces — wasi:filesystem, wasi:http, wasi:cli, wasi:clocks, wasi:random, wasi:sockets, wasi:io are all now defined in WIT.

For example, this .wit:

package example:greeter@0.1.0;

interface greet {
  hello: func(name: string) -> string;
}

world greeter {
  export greet;
}

Implemented in Rust:

wit_bindgen::generate!({
    world: "greeter",
});

struct Component;

impl exports::example::greeter::greet::Guest for Component {
    fn hello(name: String) -> String {
        format!("Hello, {}!", name)
    }
}

export!(Component);

The key point — this module is called the same way from Rust, Python, Go, JS, and C# hosts. wasm-bindgen only covered JS hosts. The Component Model covers every host.

As of May 2026, WASI 0.2 interfaces cover wasi:filesystem (files), wasi:http (HTTP client/server), wasi:cli (CLI args, env), wasi:sockets (TCP/UDP), wasi:clocks, wasi:random, wasi:logging, wasi:keyvalue (KV store, proposal), wasi:blobstore (object store, proposal). Next up: wasi:nn (ML inference) and wasi:graphics (GPU).

3. WASI 0.3 (2025 Q4) — Async Has Landed

The biggest limitation of WASI 0.2 was no async. Calling external APIs through wasi:http meant blocking. Writing a server, you could not "handle another request while one is in flight."

WASI 0.3 fixes that. GA in Q4 2025 with Wasmtime 28+ and wit-bindgen 0.36+. Two key changes.

1. async keyword added to WIT. Mark a function async and it returns a future.
2. stream<T> and future<T> types. Async streams at the standard library level.

For example:

package example:fetcher@0.3.0;

interface fetch {
  use wasi:http/types@0.3.0.{request, response};

  async fetch: func(req: request) -> result<response, string>;
}

Rust impl:

impl Guest for Component {
    async fn fetch(req: Request) -> Result<Response, String> {
        let client = wasi::http::outgoing_handler::handle(req).await?;
        Ok(client.into_response().await?)
    }
}

Internally wit-bindgen converts future/promise polling into the canonical ABI. From the host's perspective, the component now has yield points where it can pause and surrender control. Why does this matter? Because you can now multiplex many requests onto a single WASM instance. Through 0.2 the de facto pattern was "one instance per request."

Caveats — as of May 2026 only Rust (wit-bindgen) and JS (Jco) fully support async on the guest side. Go, Python, and C# are partial; full stabilization is expected late 2026.

4. Wasmtime — The Bytecode Alliance Standard

Wasmtime is the reference runtime developed jointly by the Bytecode Alliance (Mozilla, Fastly, Intel, Microsoft, Arm and others). As of May 2026 it is at 30+. The policy is one major version per month (17.0 in Jan 2024 → 30+ in May 2026) so version numbers move quickly.

One-line summary.

"The de facto reference implementation of the WASI/Component Model standard. JIT (Cranelift) compiler. Security and correctness first."

Five characteristics.

1. Cranelift JIT — its own compiler backend. The Cranelift port in SpiderMonkey uses the same code. AOT compilation is also supported via wasmtime compile.
2. Pulley interpreter — an in-house interpreter introduced in Wasmtime 25+. A fallback for environments where JIT is unavailable (iOS, JIT-forbidden hosts).
3. WASI 0.2/0.3 first-class — the standard reference implementation of the Component Model. The Rust code that wit-bindgen generates maps directly to Wasmtime's Rust API.
4. Rich host embedding APIs — Rust, C, Python, .NET embedders. Exposing host functions to a component is standardized.
5. Many forks — Cloudflare forks it for internal use alongside V8 isolates; Fastly Compute is Wasmtime-based.

Basic usage — CLI.

# 1. Build a Rust component
cargo build --target wasm32-wasip2 --release

# 2. Run it with Wasmtime
wasmtime run --invoke 'hello("world")' \
  ./target/wasm32-wasip2/release/greeter.wasm

Rust embedding.

use wasmtime::{Engine, Store, component::{Component, Linker}};

fn main() -> anyhow::Result<()> {
    let engine = Engine::default();
    let component = Component::from_file(&engine, "greeter.wasm")?;
    let linker = Linker::new(&engine);
    let mut store = Store::new(&engine, ());
    let instance = linker.instantiate(&mut store, &component)?;

    let hello = instance
        .get_typed_func::<(String,), (String,)>(&mut store, "hello")?;
    let (result,) = hello.call(&mut store, ("world".into(),))?;
    println!("{}", result);
    Ok(())
}

When to pick Wasmtime — almost always. Strongest standards tracking, new features land first, the documentation is the thickest. When in doubt, Wasmtime.

5. Wasmer — Commercial-Leaning Runtime + Registry

Wasmer is built by Wasmer Inc., founded in 2018. It is not (after a brief stay) inside the Bytecode Alliance. So its priorities lean toward productization, DX, and distribution rather than strict standards tracking.

Coordinates.

"Pragmatism first. Multi-compiler backend (Singlepass, Cranelift, LLVM). wasmer.io package registry (the wapm successor). Edge / Function hosting service."

Four differentiators.

1. You can pick the compiler. Singlepass (fast compile, slow execution), Cranelift (balanced), LLVM (slow compile, fast execution). LLVM at server start, Singlepass for JIT.
2. wasmer.io registry. An npm-like package registry for WASM. Run a published package instantly with wasmer run wasmer/python. This is the wapm successor.
3. Wasmer Edge. First-party serverless / edge hosting. Similar model to Cloudflare Workers but with WASM components as first-class.
4. WASIX. Wasmer's POSIX extension spec. WASI 0.2 plus extra syscalls (threads, fork, full sockets). But it is non-standard — Wasmer-only. As of 2026 it does not run on other runtimes.

Basic usage.

# Run a package straight from the registry
wasmer run wasmer/python -- -c "print('hello')"

# Run a local .wasm
wasmer run ./hello.wasm

Rust embedding.

use wasmer::{Store, Module, Instance, imports, Function};

fn main() -> anyhow::Result<()> {
    let mut store = Store::default();
    let wat = r#"(module
        (func (export "add") (param i32 i32) (result i32)
            local.get 0
            local.get 1
            i32.add)
    )"#;
    let module = Module::new(&store, wat)?;
    let imports = imports! {};
    let instance = Instance::new(&mut store, &module, &imports)?;
    let add = instance.exports.get_typed_function::<(i32, i32), i32>(&store, "add")?;
    println!("{}", add.call(&mut store, 7, 35)?);
    Ok(())
}

When to pick Wasmer — when you need WASIX's POSIX extensions (something close to a Linux binary environment), when you want to distribute via wasmer.io as packages, or when you want to host on Wasmer Edge. For Component Model tracking, Wasmtime is ahead.

6. WasmEdge — CNCF, Edge / IoT Focus

WasmEdge moved from CNCF Sandbox (2021) to Incubating (2024). Second State drives it but it lives under CNCF governance. The positioning is clear.

"Edge, IoT, and serverless specialized. AOT compilation first. Small binaries, low memory. Container runtime integration (runwasi, crun)."

Four differentiators.

1. AOT first. WasmEdge recommends LLVM AOT compilation by default. Start time is short (cold start in single-digit ms) and memory footprint small. Wasmtime defaults to JIT.
2. Container runtime integration. Docker Desktop supports .wasm containers via WasmEdge using docker run --runtime=io.containerd.wasmedge.v1. crun (an OCI runtime) also has a WasmEdge backend.
3. Rich wasi:nn implementations. TensorFlow Lite, OpenVINO, and llama.cpp backends. Used for LLM and vision inference at the edge. As of 2026 there is a long list of cases running 7B/13B models at the edge via the ggml (llama.cpp) backend.
4. Lots of language SDKs. Rust, Go, JS (QuickJS embedded), Python (pyo3-asyncio adapter), C/C++. For JS, QuickJS is itself compiled to WASM and runs JS on top.

Basic usage.

# AOT compile
wasmedge compile hello.wasm hello.aot.wasm

# Run
wasmedge --dir .:. hello.aot.wasm

Run a model with the llama.cpp backend.

wasmedge --dir .:. \
  --nn-preload default:GGML:AUTO:llama-2-7b.Q5_K_M.gguf \
  llama-chat.wasm default

When to pick WasmEdge — when cold start really matters (edge functions, IoT), when you want WASM containers integrated into Docker/k8s, or when running LLM / vision inference at the edge. Component Model tracking is somewhat behind, but core WASM performance is among the fastest.

7. Spin (Fermyon) — Serverless WASM Platform

Spin is the serverless WASM framework + CLI + runtime that Fermyon announced in 2022. As of 2026 it is at 3.x. Internally it uses Wasmtime and layers "function-style serverless" abstractions on top. Think of it as the WASM version of Cloudflare Workers.

Coordinates.

"WASM components = functions. Declare triggers (HTTP, Redis, Cron) in spin.toml. CLI for build, run, deploy. SpinKube for k8s."

Core concept — a Spin App = N components.

# spin.toml
spin_manifest_version = 2

[application]
name = "hello"
version = "0.1.0"

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

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

Rust handler:

use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

#[http_component]
fn handle_hello(req: Request) -> anyhow::Result<impl IntoResponse> {
    Ok(Response::builder()
        .status(200)
        .header("content-type", "text/plain")
        .body("Hello from Spin!")
        .build())
}

# Run locally
spin build
spin up

# Deploy to Fermyon Cloud
spin deploy

Spin's differentiators.

1. Component Model first. Since Spin 2, WASI 0.2 components are the default.
2. Many triggers. HTTP, Cron, Redis Stream, Kafka, MQTT. Each trigger invokes a separate component.
3. Rich host components. wasi:keyvalue (KV, Redis, Postgres), wasi:sqlite (SQLite, Turso), wasi:llm (local LLM inference), wasi:mqtt (IoT). Guest code only calls standard interfaces; Spin routes the backend.
4. SpinKube. Operate Spin apps on k8s through CRDs. Create a kind: SpinApp and k8s schedules it on Wasmtime node pools. You can run a k8s cluster that is WASM-only, no containers.

When to pick Spin — for writing serverless functions in WASM, for multi-trigger workloads (HTTP + Cron + Redis), or to run a WASM function platform on top of k8s. A self-hostable Cloudflare Workers, roughly.

8. Extism — Universal Plugin System for Every Language

Extism is a slightly different beast. One-line summary — "Do not use WASM as a runtime; use it as a plugin system." Built by Dylibso.

The core idea — how does a host application safely run code its users write? Old answer: embed Lua or JS. New answer: WASM. Whatever language you compile, ship .wasm and the host runs it in a sandbox.

Extism's differentiators.

1. SDKs for 15+ languages. Rust, Go, Python, Node.js, Ruby, PHP, Java, Kotlin, .NET, Elixir, Zig, C++, Haskell, OCaml, Swift. The widest host-side SDK coverage.
2. PDK (Plugin Development Kit). SDKs on the plugin author's side are also broad — Rust, Go, JS, AssemblyScript, Zig, C++ and more.
3. Standard ABI. Extism has its own ABI (extism_input_length, extism_alloc, extism_log_info, etc.) that standardizes host-plugin communication.
4. Partial Component Model integration. Since 2025, Extism can also load WASI components (not fully compatible but mostly working).

Host-side Go SDK example:

import "github.com/extism/go-sdk"

func main() {
    manifest := extism.Manifest{
        Wasm: []extism.Wasm{
            extism.WasmFile{Path: "count_vowels.wasm"},
        },
    }
    plugin, _ := extism.NewPlugin(ctx, manifest, extism.PluginConfig{}, nil)
    _, output, _ := plugin.Call("count_vowels", []byte("hello world"))
    fmt.Println(string(output))
}

Plugin-side Rust PDK:

use extism_pdk::*;

#[plugin_fn]
pub fn count_vowels(input: String) -> FnResult<i64> {
    let count = input.chars().filter(|c| "aeiouAEIOU".contains(*c)).count();
    Ok(count as i64)
}

When to use Extism — when adding "run user code" to your product. Examples: SaaS webhooks, DB triggers, game mod systems, automation engines for workspace tools like Notion. When "a plugin ABI that works in every host today" matters more than "100% Component Model standard."

9. Wing (Winglang) — A Language That Fuses WASM and IaC

Wing is a cloud-native programming language announced by Monada in 2022. Reached 1.0 in 2024, currently at 2.x in 2026. Its positioning is distinct.

"One language that expresses application code (runtime) and infrastructure (compile time) together. The compiler emits Terraform / CloudFormation / k8s YAML plus the WASM binary."

Core concept — a two-phase model. Every piece of code belongs to either preflight (compile time, infrastructure) or inflight (runtime, function body).

bring cloud;

let bucket = new cloud.Bucket();
let queue = new cloud.Queue(timeout: 1m);

queue.setConsumer(inflight (msg: str) => {
  bucket.put("msg-{util.nanoid()}", msg);
});

Compile with wing compile -t tf-aws and the preflight code becomes Terraform HCL (S3 bucket + SQS queue + Lambda function), the inflight code becomes .wasm or .js and lands in Lambda. Use -t sim and the same code runs on a local simulator — no AWS bill.

Why Wing matters for the WASM ecosystem — one of its inflight compilation targets is .wasm (mostly components). So a function written in Wing can deploy directly to a WASM platform like SpinKube. In Wing 2.x the wing compile -t spin-kube target is officially supported.

When to pick Wing — when you want infrastructure and application in one language, when you need multi-cloud abstraction, or when you want IaC-integrated deployment to a WASM function platform. Aiming to be the next generation after CDK and Pulumi.

10. Browser WASM — GC Proposal, Kotlin/WASM, Dart/WASM

The server-side story ran long, but WASM started in the browser. The biggest change in browser WASM during 2024-2026 is the GA of the GC (Garbage Collection) proposal in major browsers.

Before WasmGC, to compile a GC language (JVM, CLR, V8) to WASM you had to ship your own GC on top of WASM (a heap in linear memory plus mark-sweep). Result — 2-3x memory use, large code size, and conflict with the browser's GC (separate JS and WASM heaps, cross-reference inefficiency).

WasmGC defines GC objects, structs, and arrays at the WASM layer. So compilers can delegate to the host GC (V8, SpiderMonkey).

WasmGC use cases as of May 2026.

1. Kotlin/WASM (JetBrains) — Beta in 2024, Stable in 2025. The default compiler for Compose Multiplatform Web. Compose for Web apps built with Kotlin/WASM are 30-50% smaller than the dart-native equivalent and run near native speed.
2. Dart/WASM (Google) — Stable in 2024. Flutter Web's new renderer (the successor to impeller / CanvasKit) is Dart/WASM-based. Flutter Web startup time roughly halved.
3. Java/WASM (TeaVM, CheerpJ) — TeaVM officially supports a WasmGC backend. Legacy Java GUI apps (including Swing) now run in the browser.
4. OCaml/WASM (Wasm_of_ocaml) — released in 2025. Successor to Js_of_ocaml.

Non-GC languages (Rust, C/C++, Zig) still use only linear memory — they manage their own memory and do not need GC.

Another big browser-WASM topic — should the Component Model come to the browser? So far, no. Browser WASM works fine with wasm-bindgen / Jco for JS-WASM ABI, and the Component Model is optimized for server-side use. That said, Jco (a JS component runtime) also runs in the browser, so the indirect path exists.

11. Who Actually Runs WASM in Production

Enough theory. Let us look at real cases. Confirmed production usage as of May 2026, based on public announcements, blog posts, and conferences.

Cloudflare Workers

Known as V8 isolate-based, but parts of the workload have been running on Wasmtime-based components since 2024. Specifically Workers AI, parts of Durable Objects, and third-party code in Workers for Platforms. Workers Component Bindings (announced late 2025) let you deploy Component Model components directly to Workers.

Shopify Functions

Since 2022, Shopify has compiled merchant-uploaded Rust/JS into WASM and run checkout, discount, and shipping logic on it. The backend is Wasmtime. Per-request limits ~5ms and 1MB memory. As of 2026, 1B+ invocations per day.

Fastly Compute

Fastly's edge compute platform. Wasmtime-based from day one. As of 2026 the Component Model is the default (WASI 0.2). Fastly is also a core Bytecode Alliance member.

Figma

Figma's rendering core is written in C++ and compiled to WASM. Since 2017. Figma Desktop runs the same WASM module inside Electron. This is possible because once WASM SIMD and Threads went GA, it hit near-native speeds.

Adobe (Photoshop Web, Illustrator Web)

Photoshop's core image processing engine (C++) is compiled to the browser via Emscripten. Photoshop Web Beta in 2021, Illustrator Web in 2023. 30-50% of the full desktop Photoshop feature set runs in the browser.

AutoCAD Web

Autodesk has built AutoCAD's C++ core to WASM since 2018. 2D / 3D CAD with full features in the browser.

Disney+, Microsoft Office for Web

Parts of the Disney+ video player (additional codec processing) and the Excel / Word cores in Office for Web depend on C++ modules compiled to WASM.

Bloomberg Terminal Web

Launched 2024. The 1990s C++ terminal ported to WASM and now running in the browser.

12. WASM in Korea and Japan

These cases are less covered abroad but there is production usage in Korea and Japan too. Based on publicly available material.

LINE — Japan / Korea

Some of LINE's edge workloads run as WASM components. In particular, spam and malicious-content filtering for chat messages runs as a Wasmtime-based sidecar. Published on LINE Engineering Blog in 2024. The win — rule updates ship by swapping the .wasm module instead of redeploying the container.

Toss — Korea

Parts of Toss's security verification logic (client tamper detection) run as a Rust-to-WASM module. Toss Payments also uses Extism to run validation rules submitted by PG merchants. Partially disclosed at SLASH 2024.

Coupang — Korea

Coupang's search ranking inference partially runs on WasmEdge + wasi:nn — specifically ONNX models integrated into WasmEdge. Good for latency stability and multi-language model integration.

ZOZO — Japan

ZOZOTOWN's recommendation A/B testing infrastructure deploys experimental rules as WASM modules. Hot reload without rebuilds. Published on ZOZO Tech Blog in 2025.

Mercari — Japan

Parts of Mercari's payment verification (especially the identity-check rule engine) are WASM-based. Disclosed on the Mercari Engineering Blog in early 2026.

CyberAgent — Japan

Some of CyberAgent's ad-serving edge logic runs on SpinKube. One of the most aggressive Spin / SpinKube adoptions in Japan in production.

NTT DoCoMo, KDDI

Experimenting with WasmEdge as a container alternative on 5G MEC (Multi-access Edge Computing) nodes. Small footprint and fast cold start suit 5G edges. Reported in NTT Technical Review in 2025.

13. The Tool Kit — WAC, Jco, wasm-tools, Wash

Finally, the everyday tools.

wasm-tools

The Bytecode Alliance's swiss-army CLI. When in doubt, wasm-tools.

# Inspect the component header
wasm-tools component wit greeter.wasm

# Validate the component
wasm-tools validate --features all greeter.wasm

# Disassemble to WAT
wasm-tools print greeter.wasm | less

# Component -> assembled core module
wasm-tools component unbundle greeter.wasm

WAC (WebAssembly Composition)

The tool to compose larger components from smaller ones. The real value of the Component Model comes from composition. WAC enables it.

# Bundle auth + storage components into an app component
wac compose -d auth=./auth.wasm -d storage=./storage.wasm \
  -o app.wasm composition.wac

package example:app;

let auth = new auth:lib { ... };
let storage = new storage:lib { ... };
let app = new app:lib {
  authenticator: auth.authenticator,
  store: storage.store,
};

export app...;

Jco (JavaScript Component Toolkit)

The bridge between JS and the Component Model. Works both directions.

1. Call a .wasm component from JS — jco transpile greeter.wasm generates an ES module wrapper.
2. Compile a JS source into a component — jco componentize greet.js -w greet.wit produces a .wasm component (with the StarlingMonkey JS engine embedded).

# Use a Rust component from JS
jco transpile ./greeter.wasm -o ./out
# Produces out/greeter.js, out/greeter.d.ts, out/greeter.core.wasm

import { hello } from './out/greeter.js'
console.log(hello('world')) // "Hello, world!"

Wash (wasmCloud Shell)

The wasmCloud CLI / REPL. wasmCloud is yet another WASM platform — a distributed actor model with components on top. Actors communicate over the NATS message bus.

# Start a local wasmCloud host
wash up

# Start a component (actor)
wash start component ghcr.io/wasmcloud/components/http-hello-world-rust:0.1.0

# Start a capability provider (HTTP server)
wash start provider ghcr.io/wasmcloud/http-server:0.20.0

When to use wasmCloud — when distributed-actor workloads suit you (IoT, game servers, distributed simulation), when you need to deploy components dynamically across many nodes. If Spin is "serverless functions," wasmCloud is "distributed actor mesh + components."

Epilogue — How We Should See WASM in 2026

That is the WASM ecosystem map for May 2026. Once more, condensed for the head:

1. The standards solidified. WASI 0.2 (Component Model) hit GA 2024.01, WASI 0.3 (async) GA 2025 Q4. The "wait for it" phase is over.
2. Four runtimes dominate. Wasmtime (standards), Wasmer (commercial + registry), WasmEdge (edge / IoT), Spin (serverless platform). When in doubt, Wasmtime.
3. WASM's biggest value is no longer "fast browser code." It is the universal execution layer that runs the same build in browsers, servers, edges, and plugin hosts. The Component Model made that real.
4. Who is using it — large companies in production already. Cloudflare, Shopify, Fastly, Figma, Adobe, LINE, Toss, Coupang, ZOZO, Mercari, CyberAgent.
5. When to use it — (a) when you need to safely run user code (Extism), (b) when edge function cold start must be short (Spin, WasmEdge), (c) when calling multi-language libraries server-side (Wasmtime + Component Model), (d) when porting heavy native logic into the browser (Emscripten, wasm-bindgen).
6. When not to use it — ordinary microservices, code that needs deep native OS APIs, direct GPU access (wasi:graphics still in standardization), workloads happy with their existing containers.

One last line. When WASM 1.0 hit the browser in 2017, who would have predicted that nine years later Cloudflare, Shopify, and LINE would be running production on it? Seven years to GA a standard, then two more for the market to climb on top. That is the speed at which infrastructure solidifies. It is now 2026, and if your team is not using it, the next team over is.

References

• WebAssembly official site: https://webassembly.org/
• WASI 0.2 finalized announcement (Bytecode Alliance, 2024.01): https://bytecodealliance.org/articles/WASI-0.2
• WASI 0.3 — async introduction: https://bytecodealliance.org/articles/wasi-0-3
• Component Model spec: https://github.com/WebAssembly/component-model
• WIT format documentation: https://component-model.bytecodealliance.org/design/wit.html
• Wasmtime: https://wasmtime.dev/
• Wasmtime GitHub: https://github.com/bytecodealliance/wasmtime
• Wasmer: https://wasmer.io/
• Wasmer GitHub: https://github.com/wasmerio/wasmer
• WasmEdge: https://wasmedge.org/
• WasmEdge CNCF Incubating: https://www.cncf.io/projects/wasmedge/
• Spin (Fermyon): https://spinframework.dev/
• Spin GitHub: https://github.com/spinframework/spin
• SpinKube: https://spinkube.dev/
• Extism: https://extism.org/
• Extism GitHub: https://github.com/extism/extism
• Wing (Winglang): https://www.winglang.io/
• Wing GitHub: https://github.com/winglang/wing
• wasm-tools: https://github.com/bytecodealliance/wasm-tools
• WAC (WebAssembly Composition): https://github.com/bytecodealliance/wac
• Jco (JS Component Toolkit): https://github.com/bytecodealliance/jco
• wasmCloud: https://wasmcloud.com/
• Wash CLI: https://wasmcloud.com/docs/cli
• WebAssembly GC proposal: https://github.com/WebAssembly/gc
• Kotlin/WASM (JetBrains): https://kotlinlang.org/docs/wasm-overview.html
• Dart/WASM (Google): https://dart.dev/web/wasm
• Cloudflare Workers Component Bindings: https://blog.cloudflare.com/wasi-and-component-model-workers
• Shopify Functions: https://shopify.dev/docs/api/functions
• Fastly Compute: https://www.fastly.com/products/edge-compute
• Figma rendering engine and WASM: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/
• Photoshop Web (Adobe): https://blog.adobe.com/en/publish/2021/10/26/share-the-magic-of-photoshop-on-web-beta
• AutoCAD Web: https://www.autodesk.com/products/autocad-web-app/overview
• Bytecode Alliance: https://bytecodealliance.org/
• runwasi (containerd shim): https://github.com/containerd/runwasi
• crun WASM backend: https://github.com/containers/crun
• LINE Engineering Blog: https://engineering.linecorp.com/en/blog
• Toss SLASH conference: https://toss.tech/slash
• ZOZO TECH BLOG: https://techblog.zozo.com/
• Mercari Engineering Blog: https://engineering.mercari.com/
• NTT Technical Review: https://www.ntt-review.jp/