WebAssembly: History, Principles, and Applications

This article provides a comprehensive overview of WebAssembly (Wasm), tracing its origins from Mozilla and asm.js to its current role in both web and server environments.

1. Historical Background

WebAssembly’s story begins with Mozilla, the original developer of the Firefox browser, and its predecessor asm.js – a strict subset of JavaScript generated by the Emscripten compiler to enable near‑native performance in browsers. In 2017 WebAssembly was released as a W3C Recommendation, becoming the fourth programming language of the web alongside HTML, CSS, and JavaScript.

2. asm.js vs. WebAssembly

asm.js improves JavaScript performance by enforcing static typing and eliminating many dynamic checks, but it still runs as JavaScript and cannot fully exploit CPU features. WebAssembly, by contrast, uses a compact binary format, enables faster parsing (up to an order of magnitude), supports 64‑bit integers, SIMD, and other low‑level operations, resulting in smaller binaries (10‑20% smaller than gzipped JavaScript) and higher execution speed.

3. Performance Comparisons

Benchmarks show that native C/C++ code > WebAssembly > asm.js > JavaScript. Typical speed‑ups for Wasm over JavaScript range from 1.5× to 5× depending on the workload, with additional gains from binary size reduction and parallel parsing.

Examples include:

Chess AI benchmark where asm.js outperforms plain JavaScript.

Zaplib’s TypeScript vector‑length calculation optimized with ArrayBuffer versus plain arrays.

4. Code Examples

C++ source compiled to asm.js:

int f(int i) { return i + 1; }
size_t strlen(char *ptr) { char *curr = ptr; while (*curr != 0) { curr++; } return (curr - ptr); }

Generated JavaScript from Emscripten:

function f(i) { i = i|0; return (i + 1)|0; }
function strlen(ptr) { ptr = ptr|0; var curr = 0; curr = ptr; while (MEM8[curr>>0]|0 != 0) { curr = (curr + 1)|0; } return (curr - ptr)|0; }

WebAssembly binary compilation in the browser (hex‑encoded):

WebAssembly.compile(new Uint8Array(`
 00 61 73 6d 01 00 00 00 01 0c 02 60 02 7f 7f 01
 7f 60 01 7f 01 7f 03 03 02 00 01 07 10 02 03 61
 dd 00 00 06 73 71 75 61 72 65 00 01 0a 13 02
 08 00 20 00 20 01 6a 0f 0b 08 00 20 00 20 00 6c
 0f 0b` .trim().split(/[\s\r\n]+/g).map(str => parseInt(str,16)))).then(module => {
  const instance = new WebAssembly.Instance(module);
  const { add, square } = instance.exports;
  console.log('2 + 4 =', add(2,4));
  console.log('3^2 =', square(3));
  console.log('(2 + 5)^2 =', square(add(2,5)));
});

5. How to Use WebAssembly

Typical steps:

Identify performance‑critical modules in a web app (e.g., video processing, 3D rendering, AI inference).

Prototype with a small demo to verify speed‑up.

Choose a source language (C/C++, Rust, Go, etc.) and compile to Wasm using Emscripten, Rust’s wasm‑pack , or similar toolchains.

Export the .wasm file and write JavaScript “glue” code to load it via WebAssembly.instantiate or WebAssembly.compile .

6. Real‑World Web Applications

Google Earth (3D maps) – migrated from Native Client to Wasm.

Bilibili – uses Wasm‑based FFmpeg for video transcoding and Wasm‑based TensorFlow for AI thumbnail generation.

Figma – leverages the Zaplib framework (Rust + Wasm) for high‑performance canvas rendering.

Adobe Photoshop Web – compiled from C++ to Wasm via Emscripten.

Zoom Web – employs Wasm SIMD for virtual background processing.

TensorFlow.js – added a Wasm backend with SIMD and multithreading, achieving 1.7‑4.5× speed‑up.

FFmpeg.wasm – brings full‑featured media processing to the browser.

Unity/Unreal – export games to WebGL/Wasm for browser execution.

7. Server‑Side Applications and WASI

WASI (WebAssembly System Interface) provides a portable system‑call layer (files, network, clocks) enabling Wasm to run outside browsers. Use cases include:

Micro‑services / serverless functions – Wasm instances start in ~5 µs, allowing high‑density deployment.

Third‑party plugin sandboxes – Wasm’s sandboxing isolates untrusted code.

Database UDFs – Wasm can implement user‑defined functions with language flexibility and fast cold start.

Trusted Execution Environments – Wasm’s sandbox can run secure workloads on diverse CPUs.

Portable applications – a single Wasm binary runs on Linux, Windows, macOS, and cloud VMs.

Key projects: Bytecode Alliance’s Wasmtime (runtime), which reached 1.0 in 2022, offering fast, safe execution suitable for production.

8. Conclusion

The article emphasizes that WebAssembly is not a replacement for JavaScript but a complementary technology for compute‑intensive modules. Its success depends on identifying real performance bottlenecks, evaluating the cost of migration, and leveraging its strengths (speed, portability, sandboxing) where they matter most.