WebAssembly Reference

WebAssembly.instantiate() both compiles and creates an instance in one step, returning a {module, instance} pair. WebAssembly.compile() only compiles the bytes into a Module object without instantiating it, which is useful when you need to create multiple instances from the same module with different import objects. For streaming compilation from a fetch response, use WebAssembly.instantiateStreaming() which is more efficient as it compiles while downloading.

Wasm linear memory is a contiguous, growable ArrayBuffer that both JavaScript and Wasm code can read and write. It is allocated in pages of 64KB (65,536 bytes). You specify initial and optional maximum pages at creation: new WebAssembly.Memory({ initial: 1, maximum: 10 }) starts with 64KB, growable to 640KB. The page-based model simplifies bounds checking and provides deterministic memory layout. Access from JS via memory.buffer as a Uint8Array, Int32Array, or DataView.

Wasm has no native string type, so strings must be encoded into linear memory. To send a string from JS to Wasm: use TextEncoder to convert to UTF-8 bytes, then copy those bytes into the Wasm memory buffer at a known offset. To read a string from Wasm: the Wasm function returns a pointer (offset) and length, then JS uses TextDecoder on a Uint8Array slice of memory.buffer. This manual memory management is a key Wasm concept that higher-level toolchains (Emscripten, wasm-bindgen) abstract away.

i32 (32-bit integer) is the most common type, used for array indices, boolean values, and general-purpose integer math. i64 (64-bit integer) is for large integer values and timestamps. f32 (32-bit float) is for single-precision floating point, common in graphics. f64 (64-bit float) is for double-precision, used in scientific computation. Wasm is strictly typed, so you must use explicit conversion instructions (i32.wrap_i64, f64.convert_i32_s, etc.) to move between types.

The importObject is a JavaScript object whose structure mirrors the (import) declarations in the Wasm module. It passes host-provided functions, Memory instances, Table instances, and global values into Wasm. For example, if the module declares (import "env" "log" (func (param i32))), the importObject must have { env: { log: (x) => console.log(x) } }. This is the primary mechanism for Wasm to interact with the host environment (DOM, console, network, etc.).

WebAssembly.Table stores function references that can be called indirectly at runtime. Since Wasm does not support direct function pointers for security reasons, Table provides a safe alternative. call_indirect indexes into the table to dispatch a call, enabling patterns like virtual method tables, callbacks, and dynamic dispatch. The table is typed (funcref) and bounds-checked at runtime, preventing out-of-bounds function calls that could compromise safety.

WASI (WebAssembly System Interface) is a standardized API that gives Wasm modules access to operating system resources like file systems, environment variables, clocks, and random number generators. While the browser Wasm API runs in a sandboxed web context, WASI enables running Wasm outside the browser using runtimes like Wasmtime or Wasmer. WASI follows a capability-based security model where modules only get access to explicitly granted resources, making it suitable for server-side, edge computing, and plugin systems.

C and C++ use Emscripten (emcc) which provides a full POSIX-like environment. Rust uses wasm-pack with wasm-bindgen for seamless JS interop. Go has built-in Wasm support via GOOS=js GOARCH=wasm. AssemblyScript is a TypeScript-like language designed specifically for Wasm. Other languages with Wasm targets include Zig, Swift, Kotlin/Native, and C# via Blazor. The WAT text format shown in this reference is also hand-writable for low-level control and educational purposes.