WebAssembly Quick Reference

WebAssembly's core MVP defines four numeric value types: i32 and i64 for integers, and f32 and f64 for floating-point numbers, with a v128 SIMD type and reference types (funcref, externref) added by later proposals. A module is organized into sections in a fixed order in the binary format: type, import, function, table, memory, global, export, start, element, code, and data — each section is optional except that if present, they must appear in that order, which is why hand-editing a raw .wasm binary is error-prone compared to editing the WAT text representation and reassembling with a tool like wat2wasm.

A handful of commands cover most day-to-day Wasm development: wat2wasm and wasm2wat (from the WABT toolkit) convert between text and binary formats for debugging; wasm-opt from Binaryen optimizes a compiled module for size or speed with flags like -Oz for aggressive size reduction; wasmtime run executes a WASI module directly from the command line; and wasm-pack build handles the full Rust-to-browser pipeline in one step. For inspecting an unfamiliar .wasm file, wasm-objdump -x prints its section headers and import/export table, which is often the fastest way to understand what a third-party module expects and provides.

The browser-facing JavaScript API centers on a handful of methods: WebAssembly.compile takes raw bytes and returns a compiled Module; WebAssembly.instantiate takes either bytes or a Module and returns an Instance with its exports ready to call; and WebAssembly.instantiateStreaming is the preferred method for loading directly from a network response since it can begin compiling while bytes are still downloading, rather than waiting for the full ArrayBuffer to arrive first. The imports object passed to instantiate must match exactly what the module's import section declares — mismatched signatures or missing import names throw a LinkError at instantiation time rather than failing silently.