1 Introduction to Wasm on the server

WebAssembly (Wasm) began as a browser technology to run compute-heavy code at near-native speed and quickly evolved into a portable, secure, and language-agnostic execution format for the server. Rather than a physical CPU target, Wasm acts like a hardware abstraction layer that can be compiled from many languages and executed on any host via a runtime. With the introduction of the WebAssembly System Interface (WASI), Wasm gained a standardized way to interact with operating systems outside the browser, positioning it well across today’s server models—especially container-centric PaaS and serverless FaaS—while remaining standards-based and vendor-neutral.

On the server, Wasm’s key strengths are performance, security, portability, and small footprint. Benchmarks show near-native speed for single-threaded workloads, dramatically faster cold starts than traditional containers, and much smaller artifacts that improve download times and boost workload density in orchestrated environments. Its sandboxed, capability-based model isolates code by default, reducing blast radius for supply-chain risks. Being hardware-agnostic, Wasm enables “build once, run anywhere” across x86_64 and ARM64, and its efficiency makes it a strong fit for edge computing where resources are constrained. Language-wise, Wasm is broadly supportive and lightweight compared to heavyweight VMs, with ongoing proposals such as WasmGC and threads aimed at improving runtimes for garbage-collected and concurrent workloads.

Wasm shines in serverless and edge scenarios where fast startup, portability, and safety matter most, and it is gaining traction for plugins, cross-platform desktop/mobile reuse, microcontrollers, and polyglot systems. However, limitations remain: multi-threading support is still maturing, ecosystem and tooling (including debugging) can be inconsistent, and some language runtimes require extra work or size overhead. For highly concurrent, traditional PaaS services, latency can lag due to limited threading, though horizontal scaling and per-request instance models can mitigate this. Overall, the chapter frames Wasm as a pragmatic new runtime layer: already compelling for modern cloud and edge patterns, rapidly improving through open standards, and advancing toward broader applicability as proposals and tooling mature.

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