WebAssembly 128-bit SIMD (v128) provides a portable hardware vector abstraction that modern JIT engines (V8, SpiderMonkey, Cranelift) compile 1:1 into native CPU vector instructions with near-zero overhead. On x86_64 architectures, v128 instructions map directly to SSE2, SSE4.1, and AVX instructions (e.g. f32x4.mul compiles to mulps, and i8x16.add_sat_u compiles to paddusb). On ARM64 (AArch64) architectures, v128 instructions compile directly to 128-bit NEON vector instructions (e.g. fmul v0.4s, v1.4s, v2.4s and uaddsat v0.16b, v1.16b, v2.16b). Because all instructions are guaranteed deterministic across platforms (including NaN bit-pattern propagation and flush-to-zero semantics), developers achieve 3.5x to 4.2x compute speedups for matrix math, audio DSP, physics engines, and computer vision without maintaining platform-specific assembly.

Historically, WebAssembly only supported unmanaged Linear Memory (a flat byte array). Managed languages like Java, Kotlin, Dart, and OCaml compiling to Wasm were forced to ship their own runtime garbage collector inside the Wasm binary (e.g. 500KB to 2MB of overhead for dlmalloc and mark-sweep GC), suffered from memory fragmentation, and could not reference JavaScript DOM objects directly without opaque handle tables and JS wrapper calls. WasmGC introduces first-class garbage-collected types directly into the Wasm type system (structref, arrayref, eqref, anyref, and i31ref for unboxed 31-bit integers). WasmGC objects reside directly on the browser host Virtual Machine garbage-collected heap (e.g. Chrome V8 or Safari JSCore heap). They are collected alongside JavaScript objects in the same generational/incremental GC cycles, eliminate double-heap duplication, and enable zero-copy, direct passing of complex objects across the Wasm-JS boundary.

The WebAssembly Component Model is a high-level interoperability specification built on top of core WebAssembly modules. While core Wasm modules only communicate using raw primitive types (i32, i64, f32, f64), the Component Model introduces language-agnostic interface definitions expressed in WIT (WebAssembly Interface Types). WIT defines structured data types including records, variants, enums, flags, options, results, lists, resources, and interfaces. Two components written in completely different languages (e.g. a high-performance HTTP parser written in Rust and a business rules engine written in Go) can be linked together hermetically into a single self-contained component. WIT interfaces specify imports and exports, enabling safe, capability-based sandboxing where a component can only access resources explicitly passed through its WIT world.

Under the Component Model Canonical ABI, complex variable-length data structures like UTF-8 strings or byte vectors cannot simply be passed by pointer because each component may have its own distinct, isolated Linear Memory. When Component A calls an exported function of Component B passing a string: (1) Component A queries Component B Canonical ABI allocation function (cabi_realloc); (2) Component B allocates the required byte buffer in its own Linear Memory and returns the offset pointer; (3) The Canonical ABI lifts the string bytes from Component A memory and lowers them into Component B allocated memory; (4) After execution completes, Component B executes cabi_post_realloc to deallocate or retain the memory. For primitive records and fixed-size variants, the Canonical ABI uses flat lifting/lowering to pack up to 16 parameters directly into CPU registers without touching memory.

In dynamically typed and functional languages (like OCaml, Scheme, Dart, and Python), small integers are often tagged as immediate pointers to avoid heap allocations for every arithmetic calculation. WasmGC introduces i31ref: an unboxed 31-bit signed integer encoded directly inside a 32-bit or 64-bit reference pointer (with the least significant bit set as an immediate tag). The host VM never allocates heap memory or tracks GC roots for an i31ref. Instructions like ref.i31, i31.get_s, and i31.get_u allow instant creation and extraction of 31-bit numbers with zero allocation overhead and zero GC pressure, enabling functional closures and tagged union dispatch to run at native speeds.

Historically, when synchronous WebAssembly code needed to call an asynchronous browser API (such as fetch(), Web Locks, or WebGPU requestDevice()), developers used Emscripten Asyncify. Asyncify instrumented every function call in the Wasm binary with state-saving and stack-unwinding trampolines, bloating binary size by 40% to 100% and degrading CPU performance. JSPI (JavaScript Promise Integration) is an engine-level WebAssembly feature that allows Wasm stacks to be suspended and resumed natively using hardware coroutines. When Wasm calls an imported JS function that returns a Promise, the engine pauses the Wasm call stack, yields execution back to the browser event loop, and automatically resumes the Wasm execution stack at the exact instruction once the Promise resolves, without requiring code transformations or binary bloat.