WebAssembly (Wasm) is a portable binary instruction format and execution environment: code can be compiled to Wasm rather than directly to x86_64 or arm64, then transformed for the hardware where it runs. It acts as a hardware-agnostic abstraction layer, not as a physical processor platform. Originally standardized for demanding browser workloads, it enables code from languages such as C, C++, and Rust to run safely at near-native speeds. section 1.0
Figure 1.1 Wasm as an abstraction layer virtualizing over various kinds of hardware
View Wasm as a layer between compiled code and different underlying hardware architectures. section 1.0
On servers, a Wasm runtime executes modules and, with the WebAssembly System Interface (WASI), provides a portable route to operating-system resources. Rather than packaging an entire userspace environment with libraries and utilities as a traditional container does, a Wasm distribution generally packages application logic. That distinction can yield smaller artifacts and faster startup while retaining portability. section 7.1 section 1.5
Wasm is valuable where portability, isolation, and fast execution matter:
- Serverless and short-lived workloads can benefit from low memory use and reduced cold-start overhead; reported comparisons show large startup advantages over Docker for simple workloads, though application complexity changes results. section 1.2.2 section 1.3
- Edge computing can use one hardware-independent binary across resource-constrained and varied devices. section 1.2.3
- Plugins can execute isolated code, while database user-defined functions can run custom computations near data through Wasm-capable database support. section 1.3 section 5.3
- Cloud-native deployments can package Wasm artifacts with OCI conventions and use Kubernetes extensions to deploy, scale, and manage workloads. section 7.7 section 8.5
Its security model is capability-based. A module runs in a memory-safe sandbox and cannot access the native operating system unless its runtime grants a specific capability, such as standard output. This reduces a compromised component’s ability to affect other components sharing a broader environment. section 1.2.4
Figure 1.6 A native (traditional) application security model versus Wasm’s capability-based security model
Compare unrestricted native operating-system access with Wasm’s runtime-granted capability model. section 1.2.4
Wasm is language-agnostic rather than centered on one language’s execution model. More than 40 languages can compile to it, and its simple stack-based instruction set supports broad compatibility. Language support varies in maturity, however; package compatibility and historically limited garbage-collection support can constrain some targets. section 1.2.1
A low-level server-side module
A Rust “Hello, World” module accepts a string and returns that string prefixed with “Hello, ”. Building it exposes the low-level model: Wasm has linear memory and only 32- and 64-bit integer and float primitives, so strings and richer structures require manual handling or higher-level interface abstractions such as WIT. A runtime such as Wasmtime executes the resulting module and mediates system interaction. section 2.0 section 2.6
Wasm trades some familiar platform conveniences for lightweight portability. It does not require a guest OS, but real applications may face immature language ecosystems, incompatible packages, limited debugging tools, and limited multithreading support. Benchmarks can show near-native or better container-relative results, yet they do not guarantee an advantage for every workload. section 1.3 section 1.5
Figure 7.2 A side-by-side comparison of the execution models for containers and Wasm, showing how both systems provide an abstraction layer between applications and the host operating system
Compare the architectural layers of a containerized application and a Wasm application using WASI and a runtime. section 7.1
