💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> "Wasm is no longer about fast code in the browser; it is about a portable, secure isolation primitive that fits between containers and JavaScript. The 2026 Wasm fills the gap neither could." — Bytecode Alliance, State of Wasm 2025

WebAssembly (Wasm) reached an entirely new region of the stack in the nine years since the four browser vendors (Chrome, Firefox, Safari, Edge) shipped the MVP in 2017. WASI 0.2 (Preview 2) went GA on January 25, 2024, solving the "standard system interface" problem, and Component Model Preview 2 solved cross-language calling. As a result, in 2026 Wasm grows faster outside the browser, in **servers, edges, plugins, and embedded** environments.

As of May 2026 the Wasm ecosystem has no single winner. It splits into six camps: **reference runtime (Wasmtime), CNCF edge (WasmEdge), multi-compiler (Wasmer), embedded (WAMR), pure Go (wazero), and browser (V8, SpiderMonkey, JSC)**. This article walks through runtimes, WASI, the Component Model, PaaS, languages, AI/ML, plugins, and real-world adoption in one read.

1. The 2026 Wasm Map - Five Domains Beyond the Browser

The 2026 Wasm world splits into five large domains.

| Domain | Representative projects | Core value |

|---|---|---|

| Browser | V8 Liftoff+TurboFan, SpiderMonkey+Cranelift, JSC | DOM integration, JSPI, GC |

| Server runtime | Wasmtime, WasmEdge, Wasmer, WAMR, wazero | WASI, sandboxing |

| Edge / serverless | Fermyon Spin, Cloudflare Workers, Fastly Compute, Wasmer Edge | Microsecond cold start |

| Plugins | Extism, Hippo, Envoy proxy-wasm | Multi-language extension |

| AI/ML | wasi-nn, ONNX Runtime Web, WebLLM, Burn, Candle | Inference isolation, browser LLM |

The key insight is that **the real value of Wasm is not the compiled .wasm module but the Component Model interfaces written in wit**. Once WASI 0.2 went GA, a single wit file gave Rust, Go, Python, and Ruby the ability to call each other through a shared ABI - which positions Wasm less as "next-generation containers" and more as "next-generation ABI".

2. WASI 0.2 GA - The January 2024 Inflection Point

WASI (WebAssembly System Interface) is the standard surface that Wasm modules use to reach the host's files, network, clock, and other resources. Preview 1 shipped in 2019 and then drifted for five years; on January 25, 2024 **WASI 0.2 (Preview 2) went GA**, finally producing the inflection point.

The three core changes in WASI 0.2 are these. First, **interfaces split by the Component Model** - `wasi:cli`, `wasi:http`, `wasi:filesystem`, `wasi:sockets`, `wasi:keyvalue`, `wasi:logging` and friends are now distinct worlds, so hosts can expose only the permissions a module needs. Second, **a capability-based model that abandoned POSIX compatibility** - resource handles are passed explicitly instead of relying on ambient file descriptors. Third, **language-neutral interface definitions** - wit files are now standard and generate Rust, Go, and Python bindings simultaneously.

Build for the wasm32-wasip2 target (Rust 1.78+)

rustup target add wasm32-wasip2

cargo build --target wasm32-wasip2 --release

Run the resulting module (Wasmtime 21+)

wasmtime run --wasi http target/wasm32-wasip2/release/myapp.wasm

Define an interface with a wit file

cat > world.wit <<'WIT'

package example:greet@0.1.0;

interface greeter {

greet: func(name: string) -> string;

}

world greet-world {

export greeter;

}

WIT

The WASI 0.3 roadmap is centred on async and stream support. As of May 2026 0.3 is in pre-release and is targeting GA in late 2026.

3. Component Model - The Move That Turned Wasm Into an ABI

The Component Model formalises the idea that "we compose at the component level, not the module level". Classic Wasm modules could only pass i32, i64, f32, f64, and v128 values; components describe rich types - record, variant, list, option, result, string - through wit interfaces and pass them directly across languages.

// Example wit interface

package shop:checkout@0.2.0;

record cart-item {

sku: string,

quantity: u32,

unit-price-cents: u64,

}

variant payment-method {

card(string),

bank-transfer,

crypto(string),

}

interface checkout {

use cart-item;

use payment-method;

finalize: func(items: list<cart-item>, method: payment-method)

-> result<string, string>;

}

world checkout-service {

export checkout;

}

From this single wit file **wit-bindgen** generates Rust, Go, Python, and JS bindings. The caller does not need to know what language the component was written in; the host only needs to satisfy the component's imports and exports. As of May 2026 Component Model Preview 2 is stable, and the Preview 3 roadmap formalises async and stream.

4. Wasmtime - The Bytecode Alliance Reference Runtime

Wasmtime is the Bytecode Alliance's reference Wasm and WASI runtime. It is written in Rust and uses the Cranelift compiler. As of May 2026 Wasmtime 25 (LTS) is the stable release line and the project follows SemVer.

Wasmtime's strengths come in three parts. First, **first-class Component Model support** - it was the earliest runtime to stabilise component execution to match the 0.2 GA. Second, **deterministic execution and a fuel mechanism** - `Config::consume_fuel(true)` puts an instruction-level cap on a guest, which is essential in multi-tenant hosts. Third, **the pooling allocator** - component instantiation costs around 100 microseconds, which is decisive for serverless cold starts.

// Wasmtime 25 - embedding a component

use wasmtime::{Engine, Config, Store};

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

let mut config = Config::new();

config.wasm_component_model(true);

config.consume_fuel(true);

let engine = Engine::new(&config)?;

let component = Component::from_file(&engine, "checkout.wasm")?;

let mut linker = Linker::new(&engine);

wasmtime_wasi::add_to_linker_sync(&mut linker)?;

let mut store = Store::new(&engine, MyState::default());

store.set_fuel(10_000_000)?;

let instance = linker.instantiate(&mut store, &component)?;

let finalize = instance.get_typed_func::<(Vec<CartItem>, PaymentMethod), Result<String, String>>(

&mut store, "finalize"

)?;

let result = finalize.call(&mut store, (items, method))?;

Wasmtime is the underlying runtime for Fermyon Spin, Shopify Functions, Microsoft Hyperlight, and Fastly Compute - effectively making it the industry standard.

5. WasmEdge - The CNCF Edge and Server Runtime

WasmEdge, built by Second State, joined the CNCF Sandbox in 2021 and was promoted to Incubating in 2024. It is written in C++ and ships an LLVM AOT compiler.

WasmEdge's edge stack adds a number of extensions. **wasi-nn** drives ONNX, OpenVINO, and PyTorch inference; the WasmEdge TensorFlow Plugin runs ML on mobile and IoT. LangChain and llama.cpp integrations have produced a wave of LLMs running directly on Wasm.

Install WasmEdge and run an LLM

curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh \

| bash -s -- --plugin wasi_nn-ggml

8B inference (Llama 3.1 based)

wasmedge --dir .:. \

--nn-preload default:GGML:AUTO:llama-3.1-8b-instruct-Q5_K_M.gguf \

llama-chat.wasm \

--prompt-template llama-3-chat \

--ctx-size 4096

WasmEdge is one of the two runtimes Docker Desktop integrated (the other is Wasmtime), so `docker run --runtime=io.containerd.wasmedge.v1 ...` plugs directly into the container toolchain.

6. Wasmer - Multi-Compiler Plus Wasmer Edge

Wasmer (2019-) lets you pick one of three compiler backends (Cranelift, LLVM, Singlepass). It is written in Rust; as of May 2026 Wasmer 5 is the current stable release.

Wasmer's differentiator is **the broadest set of language SDKs**. Official SDKs exist for Rust, C/C++, Python, Go, JavaScript, Java, Ruby, PHP, C#, Swift, and R, so "host a wasm module from inside my language" is unusually smooth. The project also runs **WAPM (WebAssembly Package Manager)** to distribute and search wasm modules the way npm distributes JS.

// Wasmer Rust API - Cranelift backend

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

use wasmer_compiler_cranelift::Cranelift;

let compiler = Cranelift::new();

let mut store = Store::new(compiler);

let module = Module::from_file(&store, "add.wasm")?;

let import_object = imports! {};

let instance = Instance::new(&mut store, &module, &import_object)?;

let add = instance.exports.get_function("add")?;

let result = add.call(&mut store, &[Value::I32(2), Value::I32(3)])?;

**Wasmer Edge** (2023-) is Wasmer's own serverless PaaS that ships wasm components to a global edge with a single git push. It competes with Cloudflare Workers and Fastly Compute; the differentiator is that **any language Wasmer can build deploys the same way**.

7. WAMR - The Embedded Wasm Runtime From Intel

WAMR (WebAssembly Micro Runtime) is the embedded-first Wasm runtime led by Intel and is part of the Bytecode Alliance. It supports four execution modes (interpreter, classic JIT, Fast JIT, AOT) and runs in **under 50 KB of memory**, which is enough to fit on RISC-V, ARM, and Xtensa microcontrollers.

WAMR is gaining ground in IoT, automotive, and industrial PLCs. BMW announced in 2025 that part of its vehicle infotainment migrated to WAMR-based Wasm, and NVIDIA Jetson lines now use WAMR to isolate edge inference modules.

WAMR - example STM32 ARM Cortex-M build

git clone https://github.com/bytecodealliance/wasm-micro-runtime

cd wasm-micro-runtime/product-mini/platforms/zephyr/simple

RTOS embedded build with the Zephyr SDK

west build -b nucleo_f767zi -p auto

The resulting binary embeds the wasm module and loads it at boot

west flash

The weakness of WAMR is that **Component Model support is partial**. Module-level execution still dominates in embedded, but the Bytecode Alliance is actively strengthening component support across the board.

8. wazero - A Pure Go Wasm Runtime

wazero (Tetrate, 2022-) is **the only production Wasm runtime written in pure Go, without CGO**. For Go developers the headline win is that cross compilation just works: a Linux binary moves to macOS, Windows, or FreeBSD as-is, and Docker images stay under 5 MB.

// wazero - calling a wasm module from Go

package main

"context"

"os"

_ "embed"

"github.com/tetratelabs/wazero"

"github.com/tetratelabs/wazero/imports/wasi_snapshot_preview1"

)

//go:embed app.wasm

var appWasm []byte

func main() {

ctx := context.Background()

r := wazero.NewRuntime(ctx)

defer r.Close(ctx)

wasi_snapshot_preview1.MustInstantiate(ctx, r)

config := wazero.NewModuleConfig().

WithStdout(os.Stdout).

WithStderr(os.Stderr).

WithArgs("app", "--input", "hello")

_, err := r.InstantiateWithConfig(ctx, appWasm, config)

if err != nil {

panic(err)

}

wazero has been adopted as the plugin host by core Go projects including Envoy, Dapr, OpenTelemetry Collector, and Tetrate Service Bridge. The trade-off is that it has no AOT, so hot-loop throughput is roughly 60-70% of Wasmtime - but its cold start is the fastest of the bunch.

9. WAVM - The LLVM-Based Research Runtime

WAVM (WebAssembly Virtual Machine) is an LLVM-based Wasm runtime built by Andrew Scheidecker. It has been influential in academic and research settings. Active development slowed by 2026, but the project inspired the Cranelift and LLVM Wasm backends and is still used in some HPC workloads.

10. Browser Engines - V8, SpiderMonkey, JSC

Browsers remain the largest single deployment surface for Wasm. All three major engines use a two-tier compilation pipeline.

**V8 (Chrome, Edge)** pairs Liftoff (a baseline compiler that produces code in under 5 ms) with TurboFan (an optimising compiler that re-compiles hot functions in the background). V8 was also the first engine to stabilise **Wasm GC, Tail Calls, Exception Handling, SIMD, Threads, and JSPI**.

**SpiderMonkey (Firefox)** uses Cranelift as its Wasm compiler, which connects Firefox directly to the Bytecode Alliance stack. Cranelift went stable in Firefox 110, and GC, Threads, and SIMD are all stable.

**JavaScriptCore (Safari)** uses BBQ (Build Bytecode Quickly) and OMG (Optimised Machine code Generator) compilers. Safari 18 brought Wasm GC and Tail Calls to stable, and Safari 19 in 2026 added stable JSPI.

11. Wasm GC, Tail Calls, Exception Handling - Phase 4 Complete

Three central proposals reached Phase 4 (standard adoption) between 2024 and 2025.

**Wasm GC** lets Wasm modules interoperate directly with the host's GC objects (JavaScript objects, JVM objects). Previously a Wasm module had to model objects inside its own linear memory; the GC proposal adds struct, array, and ref types. As a result Kotlin/Wasm, Dart-to-Wasm, and Java-to-Wasm backends started producing genuinely usable performance.

**Tail Calls** are essential for functional languages (Scheme, OCaml, Haskell, Scala) and for compilers (JVM tail-rec) targeting Wasm. The proposal reached Phase 4 in January 2025.

**Exception Handling** lets C++, C#, and Java-to-Wasm express throw and catch naturally. It reached Phase 4 in 2024.

// Sketch of a Kotlin/Wasm module that uses Wasm GC

// Kotlin source:

// data class User(val id: Int, val email: String)

// fun greet(u: User) = "Hello, ${u.email}!"

// Conceptual compiled wat:

// (type $User (struct (field $id i32) (field $email (ref string))))

// (func $greet (param $u (ref $User)) (result (ref string)) ...)

12. JSPI, Memory64, js-string-builtins - New at Phase 4

Three additional proposals reached Phase 4 in 2025. **JSPI (JavaScript Promise Integration)** lets a synchronous Wasm function await a JS Promise, which was decisive for runtimes such as Pyodide, Ruby.wasm, and Blazor that need to call async JS IO.

**Memory64** lifts the wasm32 four-gigabyte memory limit to 64-bit addressing. It is the foundation for large-memory apps like AutoCAD Web and Photoshop Web.

**js-string-builtins** lets Wasm call JavaScript's String methods (charCodeAt, fromCharCode, length, ...) without going through a wasm import. String performance improved by 2-5x.

13. Fermyon Spin - The Wasm Serverless Frontrunner

Fermyon Spin (Matt Butcher, 2022-) packages Wasm components as HTTP-triggered serverless functions. As of May 2026 Spin 3.x is stable and the project sits above 6K GitHub stars.

Spin's headline number is **sub-millisecond cold starts**. By using Wasmtime's pooling allocator, instantiation lands around 10^-4 seconds - a different latency tier from AWS Lambda's 100-500 ms.

// Spin 3.x - HTTP trigger

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

use spin_sdk::http_component;

#[http_component]

fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {

let name = req.query().get("name").unwrap_or("World");

Ok(Response::builder()

.status(200)

.header("content-type", "text/plain")

.body(format!("Hello, {name}!"))

.build())

}

spin.toml

spin_manifest_version = 2

[application]

name = "hello-wasm"

version = "0.1.0"

authors = ["youngju@example.com"]

[[trigger.http]]

route = "/..."

component = "hello"

[component.hello]

source = "target/wasm32-wasip1/release/hello.wasm"

allowed_outbound_hosts = ["https://api.openai.com"]

Fermyon Cloud deploys Spin apps with one command (`spin deploy`), and since 2024 Fermyon Wasm Functions has run on Akamai's edge directly. Microsoft Azure announced a preview in 2025 that runs Spin as an Azure Functions Wasm worker.

14. Cosmonic wasmCloud - The CNCF Distributed Actor Model

wasmCloud (Cosmonic, 2020-) is a distributed actor platform for Wasm. It joined the CNCF Sandbox in 2022 and was promoted to Incubating in 2024. Where Spin is a "function-per-component" serverless, wasmCloud standardises actors, multi-node hosts, routing, and capability providers as a larger system.

The central concept in wasmCloud is the **capability provider**. An actor (a wasm component) only declares through a wit interface that it needs a feature like KV, messaging, or HTTP server; the actual implementation is supplied at runtime by a host node as a capability provider. That separation lets the same actor run on SQLite KV in dev and Redis KV in prod.

Operate wasmCloud with the wash CLI

wash up # start a host node

wash app deploy app.yaml # deploy actors (wadm manifest)

wash app list

wash claims inspect actor.wasm # inspect signed actor metadata

wasmCloud has been adopted in production by BMW Group, IBM, and Akamai, and is preparing for CNCF Graduation toward late 2025.

15. Cloudflare Workers - V8 and Wasm Hybrid

Cloudflare Workers runs on V8 isolates, but it treats **Wasm modules as first-class citizens**. A Wasm module imported from a JS or TS Worker runs directly in V8 with a sub-5ms cold start.

In 2025 Cloudflare also released **workerd**, the open-source version of the Workers runtime, so the same model can host Wasm outside Cloudflare's edge. workerd talks to external services (KV, D1, R2, Queue) over Cap'n Proto RPC.

// Cloudflare Workers - calling wasm from JS

export default {

async fetch(request: Request, env: Env) {

const module = await WebAssembly.instantiate(wasm, {

env: { now: () => Date.now() }

});

const buf = await request.arrayBuffer();

const resized = module.instance.exports.resize(buf, 800, 600);

return new Response(resized, {

headers: { "content-type": "image/webp" }

});

}

};

The most striking example is **Cloudflare D1**, whose backend runs SQLite-WASM inside a V8 isolate. The same wasm also runs in the browser over OPFS (Origin Private File System), giving an "isomorphic SQLite" foundation for offline-first apps.

16. Fastly Compute - The Pure-Wasm PaaS

Fastly Compute@Edge is a **pure-Wasm** serverless platform - no JS engine in the middle, just Wasmtime directly. As of May 2026 it officially supports Rust, Go (TinyGo), JavaScript (an embedded SpiderMonkey), and AssemblyScript.

The strength of Fastly Compute is its **35-microsecond cold start**, and the same binary deploys to all 80-plus Fastly PoPs. The trade-off is that you cannot drop in the full npm ecosystem because there is no V8 isolate; Fastly addressed that by building SpiderMonkey itself to Wasm and embedding it.

// Fastly Compute Rust SDK

use fastly::{Error, Request, Response};

#[fastly::main]

fn main(req: Request) -> Result<Response, Error> {

let path = req.get_path();

if path == "/healthz" {

return Ok(Response::from_status(200).with_body_text_plain("ok"));

}

let upstream = req.send("origin_0")?;

Ok(upstream)

}

17. Wasmer Edge, Suborbital Sat - Other PaaS Options

**Wasmer Edge** (2023-) is Wasmer's own PaaS that deploys wasm modules to a global edge with one command. The model resembles Fastly Compute but integrates Wasmer's multi-compiler backends and the wapm package manager.

**Suborbital Sat** (2022-) was a library for embedding wasm functions in distributed systems. It was acquired by F5 in 2024 and folded into the NGINX Wasm integration story. NGINX is now pursuing Wasm filters alongside njs.

18. Language Support - Rust First-Class, Go, Python, Java Catching Up

As of May 2026 there are more than 40 languages that target Wasm. Selected status follows.

| Language | Status | Notes |

|---|---|---|

| Rust | First-class | `wasm32-wasip1`, `wasm32-wasip2`, `wasm32-unknown-unknown` |

| Go | First-class (TinyGo) | TinyGo is the de facto standard; standard Go supports wasip1 |

| C / C++ | First-class | Emscripten, WASI SDK |

| AssemblyScript | First-class | TypeScript-like; bespoke compiler |

| Python | Experimental | py2wasm (Wasmer), Pyodide |

| Ruby | Experimental | ruby.wasm (official), shipped with CRuby 3.2+ |

| Java | Experimental | TeaVM, GraalVM Native Image |

| .NET | Experimental | Blazor, Mono+WASI |

| MoonBit | First-class | Wasm-first design; 1.0 in 2025 |

| Kotlin | Preview | Kotlin/Wasm, driven by JetBrains |

| Swift | Experimental | SwiftWasm |

| PHP | Experimental | PHP 8.4 wasm builds |

**MoonBit** (IDEA Software, 2023-) is the most interesting new language. It was designed Wasm-first and reached 1.0 in 2025. It compiles faster than Rust and produces smaller wasm binaries.

// MoonBit - Wasm-first design

pub fn fib(n : Int) -> Int {

if n < 2 {

} else {

fib(n - 1) + fib(n - 2)

}

pub fn main {

println(fib(20))

}

19. Rust Plus Wasm - The Most Mature Combination

Rust has been a first-class Wasm target since 2018, and as of May 2026 supports three core targets.

- **wasm32-unknown-unknown**: browser-oriented, only parts of std are available.

- **wasm32-wasip1**: WASI Preview 1, classic POSIX-compatible mode.

- **wasm32-wasip2**: WASI Preview 2, first-class Component Model.

Build a Rust component and inspect it

rustup target add wasm32-wasip2

cargo install cargo-component

wit interface + Rust implementation

cargo component new my-checkout --lib

cd my-checkout

Author wit/world.wit, then

cargo component build --release

Inspect component metadata with wasm-tools

wasm-tools component wit target/wasm32-wasip2/release/my_checkout.wasm

The four tools at the centre of the Rust+Wasm workflow are **wasm-bindgen** (browser), **wit-bindgen** (components), **wasm-tools** (metadata and composition), and **wasm-pack** (npm packaging).

20. Go, TinyGo, Python, Ruby - Non-Rust Languages

**Go** has shipped a `GOOS=wasip1` target since 1.21. The trade-off is that the Go runtime is heavy, so the resulting wasm is several megabytes. **TinyGo** is an LLVM-based Go compiler that produces ~100KB wasm, dropping some of the standard library but being the de facto standard in embedded and edge.

**Python** has two paths. **Pyodide** builds CPython with Emscripten and runs NumPy, Pandas, and SciPy in the browser. **py2wasm** (Wasmer) translates CPython bytecode into Wasm for faster execution.

**Ruby** has the official ruby.wasm project (Yuta Saito, 2022-), in upstream CRuby since 3.2. Rails is still hard, but Ruby DSLs that run in the browser are showing up.

require "js"

puts "Hello from Ruby #{RUBY_VERSION}!"

document = JS.global[:document]

document.body.innerText = "Ruby in the browser"

21. Java, .NET, Kotlin, Swift - The Enterprise Camp

**Java** has two paths. **TeaVM** (2014-) translates JVM bytecode into wasm, and **GraalVM Native Image** added an experimental wasm backend in 2024. Once Wasm GC stabilised, Java-to-Wasm performance entered a practical range.

**.NET** has two tracks: Blazor (browser) and **Mono+WASI** (server). Blazor WebAssembly's AOT performance improved sharply in .NET 9, and .NET 10 (November 2025) officially supports WASI 0.2.

**Kotlin/Wasm** is a JetBrains priority. Kotlin Multiplatform added a wasm target in preview in 2024, and Compose Multiplatform can now build browser UIs targeting wasm.

**SwiftWasm** is community-led but has been partly merged into the standard Swift 6.0 toolchain.

22. Wasm Plus AI / ML - wasi-nn, WebLLM, ONNX Runtime Web

Wasm is taking ground in AI inference. The central standard is **wasi-nn**: the host exposes GPU or NPU acceleration, and Wasm modules call into it through a standard API.

**WebLLM** (MLC-AI, 2023-) runs LLMs directly in the browser by combining WebGPU and Wasm to do quantised inference of Llama 3.1 8B on a laptop GPU. The same group's MLC-Chat runs the same models on phones.

**ONNX Runtime Web** converts PyTorch, TensorFlow, or scikit-learn models to ONNX and runs them on wasm, picking the best of SIMD, Threads, or WebGPU automatically.

**Burn** (Rust) and **Candle** (Rust, Hugging Face) are Rust-native ML frameworks with first-class wasm targets, so the same code can run on a server GPU and as in-browser wasm.

// Candle - shipping Rust ML to wasm

use candle_core::{Device, Tensor};

use candle_nn::{linear, Module, VarBuilder};

// A small MLP forward pass

fn forward(weights: &VarBuilder, x: &Tensor) -> anyhow::Result<Tensor> {

let l1 = linear(784, 128, weights.pp("l1"))?;

let l2 = linear(128, 10, weights.pp("l2"))?;

Ok(l2.forward(&l1.forward(x)?.relu()?)?)

}

// Build: cargo build --target wasm32-unknown-unknown

23. Extism, proxy-wasm - Plugin Systems

**Extism** (Dylibso, 2022-) targets "the same plugin API everywhere" as a universal plugin framework. It ships host SDKs for C, Rust, Go, Python, Node, Ruby, PHP, Java, and .NET, so the same wasm plugin runs identically across nine languages.

// An Extism plugin written in Rust

use extism_pdk::*;

#[plugin_fn]

pub fn count_vowels(text: String) -> FnResult<Json<serde_json::Value>> {

let count = text.chars().filter(|c| "aeiouAEIOU".contains(*c)).count();

Ok(Json(serde_json::json!({ "vowels": count })))

}

Extism Python host

manifest = {"wasm": [{"path": "count_vowels.wasm"}]}

with extism.Plugin(manifest, wasi=True) as plugin:

result = plugin.call("count_vowels", b"Hello, Wasm!")

print(result.decode()) # {"vowels": 3}

**proxy-wasm** is the wasm filter ABI shared by Envoy, Istio, NGINX, and Kong. A filter written in Rust, Go, or AssemblyScript runs unchanged on any proxy-wasm-compatible proxy.

24. Real-World Adoption - Figma, Adobe, AutoCAD, Notion

Real-world Wasm adoption started in 2017 when Figma shipped its C++ rendering engine compiled to wasm. Wasm let Figma share a single codebase between an Electron desktop and the web, which became the blueprint for every later "desktop app on the web" effort.

**Adobe Photoshop Web** (2021) is the canonical case of porting a 25-year-old C++ codebase to wasm via Emscripten. It needed 64-bit memory addressing badly enough to drive the Memory64 proposal.

**AutoCAD Web** (Autodesk) follows the same pattern - 35 years of ObjectARX C++ recompiled to wasm to support DWG editing in the browser.

**Cloudflare D1** ships SQLite as wasm and runs it inside a V8 isolate. The same wasm runs in the browser on OPFS for an offline-first story.

**Notion AI inline** moved part of its text post-processing to client-side wasm to cut response latency, and **Microsoft Office Web** runs parts of its formula engine on wasm.

25. Korean Cases - NAVER, Kakao, LINE

**NAVER Cloud Wasm Functions** (announced in 2024) is a Wasmtime-based serverless platform similar to Spin in shape, but integrated into NAVER's Korean regions and billing. Parts of NAVER's internal search and translation post-processing run on it.

**Kakao** announced R&D in 2024 on isolating part of KakaoTalk chatbot message post-processing as wasm plugins. proxy-wasm-compatible filters are under review as the adoption shape.

**LINE Yahoo Japan** (formerly Yahoo! Japan) has shipped wasm-based isolation in mail and news components and has discussed wasm sandboxing for ad surfaces.

26. Japanese Cases - Cybozu, NTT, DeNA, Mercari

**Cybozu** announced R&D on using wasm to isolate user JavaScript inside kintone. The aim is to run arbitrary user-supplied JS in a wasm sandbox to enforce multi-tenant safety.

**NTT Communications** is experimenting with wasm-based edge functions on its SDPF Edge, and **DeNA** shared at GREE Tech Conf an architecture that isolates parts of its game server's domain logic as wasm modules.

**Mercari** has presented on a search-ranking post-processor that uses wasm and wasi-nn for inference, and **Cookpad** is experimenting with ruby.wasm to evaluate user recipe DSLs.

27. Governance - Bytecode Alliance, CNCF, W3C

Wasm governance runs on three axes.

**Bytecode Alliance** is the nonprofit started in 2019 by Mozilla, Fastly, Intel, and Red Hat. It hosts Wasmtime, WAMR, Cranelift, wasm-tools, and cargo-component. As of 2024 there are more than 60 members, with Microsoft, Google, Arm, and Siemens at Premier tier.

**CNCF** hosts the cloud-native side of the Wasm world. WasmEdge and wasmCloud are at Incubating; Spin, SpinKube, and Krustlet sit across Sandbox and Incubating.

**The W3C WebAssembly Working Group** is the official home of Wasm standardisation. It runs the Phase 0 through Phase 5 proposal track, and every major proposal lands here. The core members are Google, Mozilla, Apple, Microsoft, Intel, Arm, and Fastly.

28. References

The following references let you verify the facts and numbers in this article against primary and secondary sources.

1. [WebAssembly official site](https://webassembly.org/)

2. [WASI 0.2 GA announcement (Bytecode Alliance, 2024-01-25)](https://bytecodealliance.org/articles/WASI-0.2)

3. [Component Model spec (W3C / Bytecode Alliance)](https://github.com/WebAssembly/component-model)

4. [Wasmtime official docs](https://docs.wasmtime.dev/)

5. [WasmEdge CNCF project page](https://www.cncf.io/projects/wasmedge-runtime/)

6. [Wasmer official site](https://wasmer.io/)

7. [WAMR (WebAssembly Micro Runtime) GitHub](https://github.com/bytecodealliance/wasm-micro-runtime)

8. [wazero official site](https://wazero.io/)

9. [Fermyon Spin docs](https://developer.fermyon.com/spin)

10. [Cosmonic wasmCloud](https://wasmcloud.com/)

11. [Cloudflare Workers Wasm guide](https://developers.cloudflare.com/workers/runtime-apis/webassembly/)

12. [Fastly Compute documentation](https://www.fastly.com/documentation/guides/compute/)

13. [Wasmer Edge documentation](https://docs.wasmer.io/edge)

14. [wit-bindgen GitHub](https://github.com/bytecodealliance/wit-bindgen)

15. [wasm-tools GitHub](https://github.com/bytecodealliance/wasm-tools)

16. [Bytecode Alliance official](https://bytecodealliance.org/)

17. [MDN WebAssembly reference](https://developer.mozilla.org/en-US/docs/WebAssembly)

18. [TinyGo official site](https://tinygo.org/)

19. [Pyodide](https://pyodide.org/)

20. [ruby.wasm](https://github.com/ruby/ruby.wasm)

21. [Kotlin/Wasm guide](https://kotlinlang.org/docs/wasm-overview.html)

22. [MoonBit official site](https://www.moonbitlang.com/)

23. [Extism official](https://extism.org/)

24. [WebLLM project](https://webllm.mlc.ai/)

25. [Figma WebAssembly adoption case (2017)](https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/)

Disclaimer: this article reflects information as of May 2026 and the Wasm standards and runtimes evolve quickly. For production adoption, verify against the primary sources above; treat this text as a learning and comparison reference rather than authoritative guidance.