What WebAssembly Is and What Problem It Solves
WebAssembly (Wasm) is a binary instruction format designed for a stack-based virtual machine, standardised by the W3C and supported by all major browsers. WebAssembly is not a programming language but a compilation target — code written in C, C++, Rust, Go, and other languages can be compiled to WebAssembly and run in the browser alongside JavaScript. The WebAssembly module that runs in the browser executes at near-native speed because it is a low-level binary format designed for efficient parsing and execution, rather than the high-level text format of JavaScript that must be parsed, compiled, and optimised before execution.
The JavaScript performance limitation that WebAssembly was designed to address: JavaScript’s dynamic typing and prototype-based object model make it difficult for JavaScript engines to apply the optimisations that enable near-native performance for computationally intensive code. The JavaScript engine must infer types at runtime, deoptimise when assumptions prove incorrect, and manage garbage collection — overheads that are acceptable for typical web application code but that become performance bottlenecks for the number crunching, image processing, audio processing, and physics simulation that high-performance web applications require. WebAssembly provides a statically typed, linearly addressed, sandboxed execution environment where the browser can apply ahead-of-time compilation to produce machine code that executes at a fraction of the overhead of equivalent JavaScript.
Languages That Compile to WebAssembly
The programming languages with the most mature and widely used WebAssembly compilation toolchains: Rust (whose WebAssembly support through wasm-pack and the wasm-bindgen library is the most ergonomic and production-ready, with Rust’s ownership model and zero-cost abstractions particularly well-matched to the WebAssembly environment), C and C++ (whose Emscripten toolchain has enabled the compilation of large existing codebases including game engines, image processing libraries, and scientific computing tools to WebAssembly, powering many of the most impressive WebAssembly demonstrations), and Go (whose standard library includes WebAssembly as a compilation target, though with a larger binary size than Rust or C due to the Go runtime that is included in the output).
The WebAssembly compilation approach that most enables the use of existing codebases without rewriting: the Emscripten toolchain that compiles C and C++ to WebAssembly with compatibility shims for POSIX APIs, file system emulation, and OpenGL rendering through WebGL. The C++ game engine that has been in development for years can be compiled to WebAssembly and run in the browser with the same game logic, asset loading, and rendering code that runs natively on desktop — without rewriting the game in JavaScript. This capability has enabled the browser ports of games, the browser versions of desktop applications, and the browser deployment of scientific computing tools that would have been impractical to rewrite in JavaScript.
WebAssembly Performance in Practice
The performance benchmark context that most accurately conveys WebAssembly’s performance characteristics relative to native code and JavaScript: WebAssembly typically executes at 50 to 90% of native performance for computationally intensive workloads, while equivalent JavaScript typically executes at 30 to 60% of native performance for the same workloads. The improvement that WebAssembly provides over JavaScript is most significant for the specific workloads that JavaScript’s JIT optimisation struggles with — tight loops with specific numeric computation patterns, SIMD operations, and code patterns that cause JIT deoptimisation.
The WebAssembly performance advantage that most surprises developers who expected JavaScript JIT compilation to close the performance gap: the predictability of WebAssembly performance. JavaScript performance is highly dependent on whether the JIT compiler can successfully infer types and apply optimisations for the specific code being executed — the same code can perform very differently in different call patterns. WebAssembly’s static typing and explicit binary format produce performance that is more predictable across different usage patterns, making it easier to reason about the performance of WebAssembly code and to achieve the consistent performance that real-time applications like audio processing and games require.
WebAssembly Beyond the Browser
The WebAssembly deployment environment that has generated the most commercial interest beyond browser applications: the server-side and edge execution environment that WebAssembly enables. The WebAssembly System Interface (WASI) is a standardised API for WebAssembly modules to interact with the operating system — accessing files, network connections, and other system resources — without being tied to the browser’s security model. WASI-enabled WebAssembly modules can run in server-side runtimes (Wasmtime, Wasmer, WasmEdge) as portable, sandboxed execution units that run on any WASI-compatible host regardless of the host’s operating system or hardware architecture.
The WASI WebAssembly use case that most clearly illustrates its value for server-side deployments: the edge function runtime. The edge computing platform that uses WebAssembly to execute customer functions at CDN edge nodes provides the security isolation of sandboxed execution, the startup speed advantage of WebAssembly (which starts in microseconds versus the milliseconds required for a container or language runtime cold start), and the language flexibility of any language with a WebAssembly compilation target. Cloudflare Workers, Fastly Compute, and other edge computing platforms use WebAssembly as their execution environment, enabling customers to deploy functions written in Rust, C, Go, or other languages that compile to WebAssembly alongside or instead of JavaScript.
When to Use WebAssembly
The application characteristics that most clearly justify the additional complexity of WebAssembly relative to JavaScript: the computationally intensive workload that exceeds JavaScript’s performance capability (audio and video codec implementation, image processing filters, physics simulation, cryptography, scientific computation), the existing C or C++ codebase that would need to be rewritten to use JavaScript (where Emscripten enables deployment with minimal code changes), and the language preference use case (the Rust or Go developer who prefers not to write JavaScript can use WebAssembly to contribute to web projects in their preferred language).
The WebAssembly adoption consideration that most frequently leads developers to use JavaScript instead: the interoperability overhead between WebAssembly and JavaScript. Calling JavaScript from WebAssembly and WebAssembly from JavaScript currently requires serialisation at the boundary — data must be copied between the WebAssembly linear memory and the JavaScript heap for each cross-boundary call. The application that requires frequent fine-grained interaction between WebAssembly and JavaScript may find that the boundary overhead eliminates the WebAssembly performance advantage for that specific interaction pattern, making a pure JavaScript implementation faster despite JavaScript’s lower raw computational performance. The Interface Types proposal that would eliminate this serialisation overhead is under development and will significantly expand the cases where WebAssembly provides a net performance improvement.