WebAssembly: the W3C's forgotten standard

If I ask what web standards you know, you’ll probably say HTML, CSS, JavaScript, HTTP… but what about WebAssembly? Despite being an official W3C standard since December 2019, it remains largely unknown to many frontend developers.

WebAssembly (WASM) is a portable, compact, and secure binary instruction format designed to run in modern browsers with near-native performance. And it’s everywhere.

What is WebAssembly really?

WebAssembly is a compilation target, not a programming language. You write code in C, C++, Rust, Go (with TinyGo), C# (with Blazor), or even AssemblyScript (a TypeScript subset), and compile it to a .wasm binary that browsers can execute.

Key features

Binary and compact

Unlike JavaScript, which is sent as text, WASM is a binary format. This means smaller files and faster parsing. A WASM module downloads, validates, and instantiates in milliseconds.

Portable

The same .wasm file works in Chrome, Firefox, Safari, Edge, Node.js, Deno, Bun, Cloudflare Workers… any runtime with WASM support. Write once, run everywhere (this time for real).

Safe

WASM runs in a sandboxed environment. It cannot access the file system, network, or memory outside its assigned linear memory without explicitly going through JavaScript. It’s as safe as JavaScript.

Fast

WASM compiles to native machine code via JIT compilation (or AOT in some runtimes). No interpretation, no warm-up. Code starts executing at maximum speed from the first frame.

From asm.js to W3C standard

WebAssembly didn’t emerge from nowhere. Its precursor was asm.js, a strict JavaScript subset developed by Mozilla in 2013. The idea was simple: write JavaScript in such a predictable way that engines could optimize it very effectively.

// asm.js - optimizable JavaScript
function add(x, y) {
  x = x | 0; // cast to int32
  y = y | 0;
  return (x + y) | 0;
}

asm.js worked, but had limits: it was still text, still needed parsing, and types were inferred through bitwise operations. It was a brilliant hack, but a hack nonetheless.

In 2015, Mozilla, Google, Microsoft, and Apple joined forces to create something better: WebAssembly. In March 2017, the MVP (Minimum Viable Product) launched across all four major browsers. In December 2019, the W3C declared it an official standard.

Today, WebAssembly has universal support:

• Chrome/Edge (V8): since version 57 (2017)
• Firefox (SpiderMonkey): since version 52 (2017)
• Safari (JavaScriptCore): since version 11 (2017)
• Node.js: since version 8 (2017)
• Deno, Bun, Cloudflare Workers: native support

Common misconceptions

”WebAssembly will replace JavaScript”

No. WASM doesn’t have direct DOM access, can’t handle events, can’t fetch. For that, it needs to call JavaScript. WASM and JS are designed to work together.

JavaScript remains the web’s scripting language. WASM is a tool for specific cases where we need a high level of optimization.

”WebAssembly is only for games and demos”

False. Figma uses WASM to render its graphic editor and reduced load time by 3x. Photoshop Web uses WASM for image editing. Google Earth uses WASM to render the 3D globe. Shopify uses WASM to safely evaluate third-party themes.

Real use cases:

• Image/video processing: Squoosh (Google), Photoshop Web
• Graphic editors: Figma, AutoCAD Web
• Parsers and compilers: code playgrounds, Markdown editors
• Cryptography: hashing and encryption operations
• Compression: gzip, brotli, zstd on the client
• Emulation: DOSBox, retro consoles, virtualization

”WebAssembly is hard to use”

It depends. If we have a C or Rust background, the tooling is excellent. wasm-pack (for Rust) generates bindings automatically. Emscripten (for C/C++) does the same.

If we’ve only developed in JavaScript, AssemblyScript lets us write something similar to TypeScript and compile it to WASM. We won’t get the same performance as Rust, but it’s accessible.

The current ecosystem

Languages with WASM support

• Rust: first-class, excellent tooling (wasm-pack, wasm-bindgen)
• C/C++: mature, Emscripten with years of development
• Go: TinyGo for WASM (standard Go generates very large binaries)
• C#: Blazor (Microsoft) compiles .NET to WASM
• AssemblyScript: TypeScript subset, accessible for JS devs
• Python: PyScript, Pyodide (scientific Python in the browser)

Tooling

• wasm-pack: build, test, and publish Rust → WASM projects
• Emscripten: compiles C/C++ to WASM with Web API bindings
• wasm-bindgen: generates bindings between Rust and JavaScript
• wasm-opt: optimizes WASM binaries (part of Binaryen)
• wasmtime, wasmer: standalone runtimes to run WASM outside the browser

Production use cases

Figma

Migrated its rendering engine from C++ (via asm.js) to C++ (via WASM). Result: 3x faster load time, better performance on low-end devices.

Shopify

Uses WASM to safely execute third-party theme code. Code runs in a WASM sandbox without access to sensitive resources.

Google Earth

Renders the 3D globe using WASM. The same code that ran in native Google Earth (C++) now runs in the browser.

Photoshop Web

Adobe ported Photoshop to the web using WASM. Over 20 years of C++ code running in the browser with good performance.

WebAssembly beyond the browser

Thanks to WASI (WebAssembly System Interface), WASM is no longer just for browsers. You can run WASM modules in:

• Cloudflare Workers: edge computing with instant startup
• Fastly Compute@Edge: programmable CDN with WASM
• WasmEdge, Wasmtime, Wasmer: standalone runtimes
• Docker + WASM: lightweight containers with less overhead than VMs

Solomon Hykes (Docker co-founder) said in 2019: “If WASM+WASI had existed in 2008, we wouldn’t have needed to create Docker”.

Why should we care?

WebAssembly won’t dominate the web tomorrow and JavaScript remains the undisputed king, but WASM enables:

• Porting desktop applications to the web without rewriting everything
• Processing heavy data without blocking the main thread
• Sharing complex logic between frontend, backend, and edge
• Using the best language for each problem (Rust for performance-critical, JS for UI)

If we work with image, video, audio processing, parsers, cryptography, or any CPU-intensive task, WebAssembly can be the difference between a slow and a smooth experience.

Conclusion

WebAssembly is a mature standard with universal support, solid tooling, and real production use cases. It’s not a silver bullet and won’t replace JavaScript, but it’s a useful tool we should know about.

In the next article in this series, we’ll look at when to use WebAssembly (and when not to). Because yes, there are many cases where WASM doesn’t make sense, and the overhead of communication with JavaScript can destroy any performance gains.