1 Introduction to Wasm on the server

WebAssembly began as a way to run high‑performance code safely in the browser, but with the introduction of WASI it has become a portable, standards‑based runtime for the server as well. Rather than being tied to a specific chip, Wasm acts like a hardware‑agnostic instruction set that hosts translate to native code, making the same binary runnable across machines and environments. This portability aligns naturally with today’s server‑side landscape—spanning IaaS, PaaS, FaaS, containers, and the edge—where Wasm modules can be packaged and orchestrated similarly to containers while remaining smaller, quicker to start, and more isolated by default.

The chapter highlights Wasm’s core strengths: language‑agnostic compilation, lightweight runtimes, and a capability‑based sandbox that tightly controls access to the host system. In practice, these traits translate to near‑native performance in many scenarios, dramatically faster cold starts, tiny artifacts that boost workload density, and seamless execution across architectures like x86_64 and ARM64. These qualities make Wasm particularly compelling for serverless and edge computing, where startup latency, memory footprint, and portability matter most, and its open, vendor‑neutral standards reduce lock‑in while enabling consistent deployment across cloud, on‑prem, and edge environments.

At the same time, the chapter is clear about trade‑offs and where Wasm shines today. It excels for short‑lived functions, event‑driven and edge workloads, plugins, and polyglot or cross‑platform applications, and it is gaining traction even on microcontrollers. Current limitations include immature multi‑threading support and uneven ecosystem maturity, which can affect latency under heavy concurrency and complicate library compatibility and debugging. These gaps are being addressed through active proposals (such as threads and garbage‑collection support) and practical patterns like scaling via many short‑lived instances, positioning Wasm as a powerful complement to—rather than a wholesale replacement for—traditional containers and platforms.

Wasm as an abstraction layer virtualizing over various kinds of hardware.

Compiling to Wasm from various languages.

Java and Wasm's similarities

Running a PHP Wasm without garbage collection application in the browser.

Dockerfiles for a Docker container and a Wasm container

A native (traditional) application security model vs. Wasm's capability-based security model.

• Wasm is akin to an ISA like x86_64, in the sense that your code can target it for compilation. But it is not a real platform, and instead, just virtualizes actual hardware.
• Wasm apps can run outside of browser primarily through the Wasm System Interface (WASI) that allows communication with the OS.
• Docker supports running two types of containers: the traditional Docker container, and the newly introduced Wasm container.
• Wasm's language-agnosticism makes it so that over 40 languages can be compiled to it, but that is a double-edged sword as support for a particular language might not be as mature as it is for others.
• While benchmarks show that standalone Wasm apps can be 10-50% faster than containerized apps, real-world applications can struggle due to Wasm's lack of support for multi-threading.
• Wasm, when paired with serverless and its scale-to-zero requirement, leads to 80% faster execution times on average when compared to traditional serverless technologies.
• A Wasm binary is completely independent of the platform or hardware where it is built and can theoretically run on any system due to its hardware-agnosticism property.
• Wasm employs a capability-based security model that restricts the binary to only access the native OS through specific capabilities made available by the Wasm runtime.
• Aside from serverless and edge computing, Wasm has found its footing in mobile and desktop applications, microcontrollers, smart contracts, and polyglot programming.
• When targeting Wasm, it is commonplace to make sacrifices of particular packages that do not support Wasm.

FAQ