Use Cases & When to Use Wasm

WebAssembly is not a hammer looking for nails. It shines in specific scenarios and adds unnecessary complexity in others. This lesson maps the real-world use cases and gives you a decision framework.

Use case 1: Plugin systems

Many applications need user-extensible behaviour — think IDE extensions, game mods, data-pipeline transforms, or CI/CD step executors. Traditionally this means embedding a scripting language (Lua, Python, JavaScript) with all of its security and versioning headaches.

With Wasm + WASI you can:

• Accept plugins written in any language (Rust, Go, C, AssemblyScript).
• Run them in a strict sandbox — no filesystem, no network unless you grant it.
• Load, unload, and version them at runtime without restarting the host.

Projects using this pattern: Envoy (filter plugins), Zellij (terminal multiplexer plugins), Shopify (checkout extensions), Extism (plugin SDK).

Use case 2: Edge and serverless

Edge platforms like Cloudflare Workers, Fastly Compute, and Fermyon Spin run Wasm modules on their global PoP networks. The key advantage over containers:

• Cold start in microseconds — no OS process, no container runtime, no JVM.
• Strong isolation — each request gets its own Wasm instance.
• Tiny footprint — a Wasm module is kilobytes, not megabytes.

# Deploy a Rust function to Fermyon Spin
spin new --template http-rust my-api
cd my-api
spin build
spin deploy

Use case 3: Sandboxed execution of untrusted code

Online code judges, notebook runners (like this course’s own WasmRunner), CI step isolation, and customer-defined logic in SaaS all need to run arbitrary code safely.

Wasm’s sandboxed memory model guarantees:

• A module cannot access host memory outside its own linear memory.
• A module cannot make arbitrary syscalls — only the WASI imports the runtime exposes.
• A module cannot spin up threads or processes on its own.

This makes Wasm the most lightweight safe sandbox available — lighter than Docker, lighter than gVisor, lighter than eBPF sandboxes.

Use case 4: Portable CLI tools

A .wasm binary compiled against WASI is a portable executable that runs on any OS with a WASI runtime — no cross-compilation matrix required.

# Distribute a CLI tool as a .wasm binary
wasmtime my-tool.wasm -- --input file.csv --output result.json

# Or package it with wasmer for one-liner install
wasmer publish && wasmer run yourname/my-tool -- --help

Decision framework

flowchart TD
  Q1{"Need to run\nuntrusted code?"}
  Q1 -->|Yes| Wasm1["Use Wasm sandbox\n(WASI + wasmtime/wasmer)"]
  Q1 -->|No| Q2{"Performance-critical\ncompute in the browser?"}
  Q2 -->|Yes| Wasm2["Compile C/Rust/Go\nto wasm32-unknown-unknown"]
  Q2 -->|No| Q3{"Need edge cold-start\n< 1 ms?"}
  Q3 -->|Yes| Wasm3["Use Wasm on\nedge platform"]
  Q3 -->|No| Q4{"Plugin system\nacross languages?"}
  Q4 -->|Yes| Wasm4["Component Model\n+ WASI"]
  Q4 -->|No| Native["Stick with\nnative code / containers"]

When to reach for WebAssembly

When Wasm is NOT the right choice

Scenario	Better alternative
Simple CRUD web APIs	Node.js / Go / Python — less toolchain complexity
Long-running stateful services	Docker containers — better observability tooling
GPU-accelerated ML inference	CUDA / WebGPU — Wasm has no GPU access
Native desktop apps	Tauri / Electron / native — OS integration is easier
Scripts and glue code	Bash / Python — Wasm startup overhead not worth it

🦾 Wasm wins on safety + portability, not on raw throughput

Do not use Wasm because it is “fast.” Use it because you need a safe sandbox, a portable binary, or a language-agnostic plugin interface. Raw throughput on the server is often better served by native binaries.

Trade-offs

Option	Benefit	Cost
WASI capability-based security	Much safer — a plugin or sandboxed piece of code only gets what’s explicitly granted, no ambient access	Not fully POSIX-compatible; some native libraries that assume ambient filesystem/network access don’t port in smoothly
Edge/serverless Wasm vs. containers	Microsecond-scale cold starts and a much smaller footprint than containers — a good fit for edge PoPs	The container ecosystem still has broader tooling, more battle-tested orchestration, and wider library support

Common mistakes

• Expecting filesystem or network access to “just work” without explicitly granting the capability to the WASI runtime — code fails silently or throws a permission error
• Reaching for Wasm as a container replacement in every case, without recognizing container tooling, orchestration, and library support are still more mature
• Deploying to an edge platform without first checking whether the target runtime actually supports the SIMD or threads proposal being used — these are still opt-in, not universal

💡 Real-world example

Cloudflare Workers and Fastly Compute both use Wasm sandboxing to isolate thousands of tenants’ code on the same edge network, achieving cold starts on the order of microseconds — something a container can’t match.

Which property makes Wasm especially attractive for edge/serverless platforms?

Large memory footprint Microsecond cold starts with strong per-request isolation Native GPU access Built-in HTTP server

Which real-world project uses Wasm for extensible filter plugins?

Nginx Envoy HAProxy Caddy

Why is Wasm NOT a good fit for GPU-accelerated ML inference?

Wasm modules are too large Wasm has no GPU access WASI does not support floating-point math Wasm cannot load binary data

What makes Wasm the most lightweight safe sandbox compared to Docker?

Wasm uses kernel namespaces like Docker Wasm modules share memory across instances Wasm has no OS process, no container runtime, and enforces memory isolation in software Wasm runs on a hypervisor

Submit

Mark as complete