16 Patterns for Crossing the WebAssembly Boundary (And the One That Wants to Kill Them All)

WebAssembly is fast. We all know that by now. What almost nobody talks about is the hidden toll you pay every time you try to talk to it.

The moment your JavaScript code needs to pass a measly string to a WASM module, or your WASM tries to touch a DOM node, you slam face-first into the boundary — a literal wall between two worlds with fundamentally opposed type systems, memory models, and execution paradigms. On one side, JS breathes UTF-16 strings, garbage-collected live objects, and async promises. On the other, WASM is spartan: it only understands numeric primitives like i32 or f64, raw linear memory, and strictly synchronous execution.

Crossing this boundary is never free. Every interaction has a price, and depending on the strategy you choose to pay it, that cost can range from mathematically negligible to a painful "why on earth did I bother compiling this to WASM?"

What you're about to read is the definitive catalog of every known pattern for crossing this boundary, from the most trivial to the most exotic. To make sense of it all, I've organized them into three fundamental blocks based on the exact question they answer:

Block 1 — The Primitives: What things can actually cross the boundary and how do they do it?

Block 2 — Memory Strategies: How do you move heavy data efficiently without killing performance?

Block 3 — Flow Architectures: How do you orchestrate and design the conversation between both sides?

And to close, we'll talk about the Component Model — the emerging standard that aspires to turn all of these patterns into museum pieces.

---

Block 1 — The Primitives

What can cross the boundary, and how?

Before optimizing anything, you need to understand what can actually travel between the two worlds. WebAssembly's binary interface (ABI) is minimalist: numbers in, numbers out. Everything else — strings, objects, callbacks, DOM references — requires a translation layer.

The five patterns in this block are the foundation. Every advanced technique in the later blocks is built on top of one or more of these. Think of them as the alphabet: you need to know the letters before you can write sentences.

Pattern 1: Scalar Pass-through

The only thing WebAssembly can natively pass across its boundary: numbers.

Rust side:

#[no_mangle]
pub extern "C" fn add(a: i32, b: i32) -> i32 {
    a + b
}

JavaScript side:

const result = wasm.instance.exports.add(2, 3); // Returns 5

Functions that take integers (i32, i64) or floats (f32, f64) and return the same have zero serialization overhead. The values go straight onto the WASM stack. No memory allocation, no encoding, no copies.

This is the ideal case. The trouble starts when you need to pass a string, an array, or a JSON object. At that point, you leave paradise.

When to use it: Pure math functions, hash computations, physics calculations, or any logic where inputs and outputs are strictly numeric.

The tax: None. This crossing is completely tax-free.

---

Pattern 2: Pointer + Length Convention

The fundamental building block for passing anything more complex than a bare number. Both sides of the boundary agree on a strict protocol:

1. The caller writes the data into WASM's linear memory.
2. The caller passes two integer values (typically i32 or usize): the memory offset where the data starts (pointer) and the exact length in bytes.
3. The callee reads and processes from that memory region.

Rust side:

#[no_mangle]
pub extern "C" fn alloc(len: usize) -> *mut u8 {
    let mut buf = Vec::with_capacity(len);
    let ptr = buf.as_mut_ptr();
    std::mem::forget(buf); // Prevent Rust from freeing this memory automatically
    ptr
}

#[no_mangle]
pub unsafe extern "C" fn dealloc(ptr: *mut u8, len: usize) {
    // Reconstruct the Vec so Rust's allocator frees it when it goes out of scope
    let _ = Vec::from_raw_parts(ptr, 0, len);
}

#[no_mangle]
pub unsafe extern "C" fn process_string(ptr: *const u8, len: usize) -> i32 {
    let slice = std::slice::from_raw_parts(ptr, len);
    if let Ok(s) = std::str::from_utf8(slice) {
        s.len() as i32 // Simulate doing something with the string
    } else {
        -1
    }
}

JavaScript side:

const encoder = new TextEncoder();
const bytes = encoder.encode("Hello, WASM");

// 1. Ask Rust for memory
const ptr = wasm.instance.exports.alloc(bytes.length);

// 2. Write the bytes into linear memory
const memory = new Uint8Array(wasm.instance.exports.memory.buffer);
memory.set(bytes, ptr);

// 3. Pass the pointer and length to Rust
const result = wasm.instance.exports.process_string(ptr, bytes.length);

// 4. Free the memory explicitly to avoid leaks
wasm.instance.exports.dealloc(ptr, bytes.length);

This is exactly what every toolchain and code generator does under the hood. It's a completely manual process, highly error-prone, and requires you to manage memory allocation and deallocation yourself from JavaScript. In return, it gives you total, absolute control — no black boxes, no magic.

When to use it: When you need maximum control over memory, when you're writing very low-level base libraries, or simply when you're learning how WebAssembly's linear memory actually works.

The tax: Manual memory management. You pay the cost of encoding and decoding data (like TextEncoder), and you accept the constant risk of critical mistakes: using memory that's already been freed (use-after-free), freeing it twice (double-free), or simply forgetting to call dealloc and causing a memory leak that will eventually take down the browser tab.

---

Pattern 3: Opaque Handles / externref

Before the Reference Types standard landed in WebAssembly, life was miserable if your WASM code needed to hold a live reference to a JavaScript object (like a DOM node, a WebSocket connection, or a Canvas context). You had to build a lookup table manually on the JS side.

The old way (userland):
You'd create an array in JS. Every time you wanted to hand an object to Rust, you'd stick it in the array and give Rust the index (a plain i32). Rust would hand that i32 back when it needed to interact with the object, and JS would look it up in the array. It works, sure, but the lifecycle is a nightmare: when do you delete entries from the array so the garbage collector (GC) can reclaim memory? What happens if you create circular references?

The modern way (externref):
With the externref type (now standardized and implemented in all modern engines), WebAssembly can hold opaque references to JavaScript objects directly, no hacks required.

Rust side:

// At the low level, externref is a type managed by the engine.
// (Note: In real-world ecosystems, wasm-bindgen wraps this as the JsValue type.)

#[link(wasm_import_module = "env")]
extern "C" {
    // We import a JS function that knows what to do with the object
    fn js_set_text_content(node: externref, text_ptr: *const u8, len: usize);
}

#[no_mangle]
pub unsafe extern "C" fn process_node(node: externref) {
    // Rust holds the DOM object, but it's a black box.
    // It can't read or mutate it. It can only hand it back to JS.
    let msg = "Updated from Rust";
    js_set_text_content(node, msg.as_ptr(), msg.len());
}

JavaScript side:

// We pass the actual DOM object directly to the WebAssembly function
const button = document.getElementById("my-button");
wasm.instance.exports.process_node(button);

The absolute key to this pattern is the word "opaque." Rust receives the object, stores it in its registers or its own internal tables (using WebAssembly.Table), but to Rust it's inscrutable. It cannot inspect its properties or call its methods internally.

The only things it can do are: store it, pass it from one function to another, and hand it back to JavaScript so that JS can do the real work. The massive advantage is that the JavaScript engine (V8, SpiderMonkey, JavaScriptCore) now understands what's going on and automatically manages the lifecycle and garbage collection of that reference. No more memory leaks caused by your manual table.

When to use it: Whenever WASM needs to "remember" or retain a JS object — DOM nodes, event handlers, network resources, class instances. It eliminates in one stroke the need to maintain index tables in JavaScript and all the associated garbage collector headaches.

The tax: WebAssembly remains blind to the object. Every time you want to do something useful with it (read a property, modify its state), you have to pay the toll of crossing the boundary back to JavaScript. Holding the reference in Rust's pocket is free; trying to use it is not.

---

Pattern 4: Function Tables / call_indirect

How does WebAssembly call different JavaScript functions dynamically, without having to hardcode and declare every single import in the Rust source code?

The answer is WebAssembly.Table. It's essentially an array of function references that lives at the boundary and is accessible to both JS and WASM. WASM uses a special virtual-processor-level instruction called call_indirect, passing it an integer index. The engine looks up which function sits at that index in the table and executes it at runtime.

Rust side:

// In WebAssembly, a function pointer isn't a memory address.
// It's literally an index (an i32) into a WebAssembly.Table.

#[no_mangle]
pub unsafe extern "C" fn invoke_dynamic(callback_index: usize, value: i32) {
    // We trick the compiler by transmuting the integer index to a function pointer.
    // When compiled to WASM, this magically becomes a call_indirect instruction.
    let callback: extern "C" fn(i32) = std::mem::transmute(callback_index);

    // Execute the JS function pointed to by the index
    callback(value);
}

JavaScript side:

// 1. Create a table capable of storing function references
const table = new WebAssembly.Table({ initial: 10, element: "anyfunc" });

// 2. Place our JS function at index 0
table.set(0, (val) => console.log("Callback fired from Rust with value:", val));

// (When instantiating the WASM module, pass this table in the imports under env.table or similar)

// 3. Tell Rust to execute index 0
wasm.instance.exports.invoke_dynamic(0, 99);

This is exactly how Rust and C++ map their function pointers to the JavaScript world. When you have a function pointer in your compiled code, it doesn't point to WASM's linear memory — it points to a slot in this table. It's also the architectural foundation for building plugin systems where different WASM modules can register callbacks with each other.

When to use it: Callbacks, UI event handlers, polymorphic dispatch, or plugin architectures where the exact set of functions you'll invoke isn't known at compile time.

The tax: You pay one level of indirection (index → function lookup → execution). The CPU cost per call is tiny, nearly negligible, but the table itself requires extremely careful management if you're doing it by hand. You have to explicitly register functions, track which indices are free, and clean them up when a callback is no longer needed to avoid blowing past the table's limits.

---

Pattern 5: wasm-bindgen / Emscripten Glue

This isn't a separate interop pattern. It's a massive automation layer built squarely on top of the foundations of Patterns 2, 3, and 4 that we just covered.

Tools like wasm-bindgen in Rust handle generating all the intermediary JavaScript code (glue code) for you. Specifically, they automate:

• String conversion using TextEncoder and TextDecoder (Pattern 2).
• Table management for JS object references or native externref usage (Pattern 3).
• Function table setup for injecting and executing callbacks (Pattern 4).
• Manual linear memory allocation and deallocation behind the scenes.

Rust side:

use wasm_bindgen::prelude::*;

// This simple macro triggers all the plumbing
#[wasm_bindgen]
pub fn greet(name: &str) -> String {
    format!("Hello, {}!", name)
}

You write idiomatic Rust. The macro intercepts compilation and automatically generates the pointer-plus-length protocol, the memory allocation, and the JavaScript shim.

Critical insight: wasm-bindgen is to these low-level patterns what an ORM is to raw SQL queries. It's not a new mechanism — it's a code generator that hides the complexity. Understanding exactly what it generates beneath that macro is your only lifeline for debugging bottlenecks and knowing which critical parts of your application need you to skip the tool and cross the boundary manually.

When to use it: During prototyping, in the vast majority of business application code, and whenever development speed matters more than squeezing the last microsecond out of the processor.

The tax: The size of the glue code that will bloat your final JavaScript bundle. You're accepting automatic memory copies that might be unnecessary for your particular use case. On top of that, the very convenience of the abstraction is a trap: it makes it dangerously easy to cross the boundary thousands of times inside a for loop without ever noticing the cost you're paying.

Quick decision guide:

• Only numbers? → Pattern 1
• Occasional strings? → Pattern 2 / wasm-bindgen
• JS objects? → Pattern 3

---

Block 2 — Memory Strategies

How do you move data efficiently?

Once you know what can cross the boundary, the next question is how much it costs. The default answer — "copy everything" — works, but it's the equivalent of shipping goods by air when a pipeline would do. The four patterns in this block are variations on the same theme: reducing or eliminating copies. They range from simple (creating a view instead of a copy) to sophisticated (agreeing on a binary layout so both sides can read the same bytes without any transformation). If your application moves more than trivial amounts of data across the boundary, at least one of these patterns will save you.

Pattern 6: Typed Array Views

Instead of copying data out of WASM memory into JS, you create a view directly on top of WASM's linear memory:

Rust side:

#[no_mangle]
pub extern "C" fn process_image(width: usize, height: usize) -> *const u8 {
    static mut BUFFER: Vec<u8> = Vec::new();
    unsafe {
        BUFFER.resize(width * height * 4, 255);
        BUFFER.as_ptr()
    }
}

JavaScript side:

const ptr = wasm.instance.exports.process_image(800, 600);
const wasmMemory = wasm.instance.exports.memory;

// Create the view over WASM memory — zero copies
const pixels = new Uint8ClampedArray(wasmMemory.buffer, ptr, 800 * 600 * 4);
const imageData = new ImageData(pixels, 800, 600);
ctx.putImageData(imageData, 0, 0);

Zero copies. JS reads directly from WASM memory. The typed array (Uint8Array, Float32Array, Int32Array, etc.) is just a view — a window into the same underlying ArrayBuffer.

The critical gotcha: If WASM calls memory.grow(), the underlying ArrayBuffer gets detached and all existing views are invalidated. You must re-create them after any potential growth. This is the single most common source of bugs with this pattern.

Mitigation: Pre-allocate enough memory upfront, or re-create views on every access (slightly slower but safe).

When to use it: Reading large results from WASM — rendered images, audio buffers, computed arrays. Anywhere you need to read (not write) massive data with zero overhead.

The tax: Fragility with memory.grow(). From JS's perspective it's read-only (writing through views is possible but risky if WASM is also writing).

---

Pattern 7: Memory Pool / Arena Allocation

Instead of allocating and freeing individual objects, you pre-allocate a large block of linear memory and use a simple bump allocator:

Rust side:

const ARENA_SIZE: usize = 1024 * 1024; // 1 MB
static mut ARENA: [u8; ARENA_SIZE] = [0; ARENA_SIZE];
static mut HEAD: usize = 0;

#[no_mangle]
pub unsafe extern "C" fn arena_alloc(size: usize) -> *mut u8 {
    let ptr = ARENA.as_mut_ptr().add(HEAD);
    HEAD += size; // Advance the pointer, no complex logic
    ptr
}

#[no_mangle]
pub unsafe extern "C" fn arena_reset() {
    HEAD = 0; // Free everything in one shot
}

All allocations advance the pointer. No individual free() calls. When you're done with the whole batch, reset the pointer to the beginning.

The web-specific benefit is subtle but important: by keeping all data inside WASM's linear memory, you avoid creating thousands of small JS objects that the garbage collector has to track. Arena allocation means the JS GC has nothing to do — all data lives in a single large ArrayBuffer that the GC sees as one object.

When to use it: Processing pipelines where you allocate many temporary objects (e.g., parsing, transformation). Per-frame allocation in games or visualizations.

The tax: You can't free individual allocations. The entire arena is all-or-nothing. It requires estimating the maximum memory you'll need ahead of time.

---

Pattern 8: Zero-Copy with Format-Aligned Layout (Arrow C Data Interface)

The most sophisticated zero-copy pattern available today. The key idea: if both sides of the boundary agree on an identical memory layout, you don't need to serialize or deserialize anything. You just share the pointer.

Apache Arrow defines a columnar memory layout that is identical across every implementation — Arrow C++, Arrow JS, Arrow Rust. When a Rust library compiled to WASM produces an Arrow RecordBatch, the bytes in WASM memory are already in the format Arrow JS expects.

The arrow-js-ffi library implements the Arrow C Data Interface in JavaScript, allowing it to read Arrow data directly from WASM memory:

JavaScript side (using arrow-js-ffi):

import { parseRecordBatch } from "arrow-js-ffi";

// Rust returns pointers to its internal Arrow structures
const ffiRecordBatch = wasmRecordBatch.intoFFI();

const recordBatch = parseRecordBatch(
    wasmMemory.buffer,
    ffiRecordBatch.arrayAddr(),
    ffiRecordBatch.schemaAddr(),
    false  // false = zero-copy view, don't move data to JS
);

This isn't limited to Arrow. Any format with a deterministic binary layout — FlatBuffers, Cap'n Proto, Protocol Buffers (wire format) — can achieve similar results. The principle is: agree on the byte layout at design time, and sharing becomes free at runtime.

DuckDB-WASM uses this approach to pass query results from its C++ engine (compiled to WASM) to JavaScript without serialization.

When to use it: Analytical workloads, large tabular datasets, any scenario where both sides can use the same binary format.

The tax: Both sides must implement the same format. Memory lifecycle management is complex — who owns the data? When is it safe to free it? Views over WASM memory are invalidated if memory.grow() is called.

---

Pattern 9: String Passing Optimizations

Strings deserve their own pattern because they are the single most expensive data type to cross the boundary.

The fundamental problem: WASM operates in UTF-8. JavaScript engines use UTF-16 internally (or Latin-1 for ASCII-only strings). Every string crossing requires a transcoding step — TextEncoder (JS→WASM) or TextDecoder (WASM→JS) — which is O(n) in the string's length.

There are four strategies on a spectrum:

a) Standard TextEncoder/TextDecoder — The usual approach. It works. Costs O(n) per crossing. Acceptable for occasional string passing.

b) Deferred decoding — Don't convert to a JS String unless it's absolutely necessary. Keep strings as raw UTF-8 byte arrays (Uint8Array views over WASM memory) and only decode when you need to render to the DOM or pass to a JS API that requires a String. Many intermediate operations (comparison, hashing, searching) can work directly on UTF-8 bytes.

c) stringref proposal (Future) — A proposed WASM type that would let WASM hold direct references to engine-managed strings, avoiding UTF-8↔UTF-16 conversion entirely. WASM could call operations on the string (length, substring, compare) through imported functions without ever copying the string data. Still in proposal stage.

d) JS String Builtins — A more pragmatic near-term alternative. Safari 26.2 shipped JS String Builtins, which reduce the need for JavaScript glue code when passing strings, eliminating some of the overhead without requiring a new type system.

When to use it: Any application that passes many strings or large strings across the boundary — text editors, parsers, search engines, internationalization systems.

The tax: UTF-8↔UTF-16 transcoding is unavoidable today for any string that must become a JS String. The deferred decoding pattern changes when you pay the tax, not whether you pay it.

Quick decision guide:

• Small data (<10 KB)? → Just copy it
• Large and read-only? → Typed Array view (Pattern 6)
• Streamed continuously? → Ring buffer (Pattern 12)

---

Block 3 — Flow Architectures

How do you orchestrate the communication?

Blocks 1 and 2 answer "what can cross" and "how to move data." This block answers the harder question: "how do you design the conversation?" The raw cost of a single boundary crossing is small (~100ns). The problem is frequency and coordination. A naively written render loop can cross the boundary 50,000 times per frame. An async web API call can stall your entire WASM stack. The six patterns here aren't about moving bytes faster — they're about restructuring the interaction so you cross the boundary fewer times, in smarter ways, and without blocking when you shouldn't.

Pattern 10: Batch / Coalesce

The simplest flow optimization: instead of making N boundary crossings, make 1.

Rust side:

#[repr(C)]
pub struct Point { x: f64, y: f64 }

#[no_mangle]
pub unsafe extern "C" fn process_point_batch(ptr: *const Point, len: usize) {
    let points = std::slice::from_raw_parts(ptr, len);
    for p in points {
        // Do the heavy lifting here, without crossing the boundary
        let _calc = p.x * p.y;
    }
}

JavaScript side:

// 1 boundary crossing instead of 10,000
const buffer = new Float64Array(wasm.instance.exports.memory.buffer, ptr, points.length * 2);
points.forEach((p, i) => {
    buffer[i * 2] = p.x;
    buffer[i * 2 + 1] = p.y;
});
wasm.instance.exports.process_point_batch(ptr, points.length);

This is the equivalent of batch inserts in a database vs. individual inserts. The per-call overhead of crossing the JS↔WASM boundary is small (~100ns), but multiplied by 10,000 calls per frame, it dominates the total cost.

The Yew framework (Rust UI framework in WASM) uses this for DOM updates: instead of calling JS for each individual DOM mutation, it queues all mutations during virtual DOM reconciliation and flushes them in a single call.

When to use it: Any loop that calls WASM functions. Any scenario where you can accumulate work and send it in bulk.

The tax: You need to design your API for batch operations. Single-element functions are simpler to implement but more expensive to call repeatedly.

---

Pattern 11: Command Buffer / Opcode Stream

An evolution of batching. Instead of passing data, you pass an encoded instruction stream across the boundary:

Rust side:

const CMD_CREATE_ELEMENT: u8 = 1;
const CMD_SET_TEXT: u8 = 2;

#[no_mangle]
pub unsafe extern "C" fn generate_ui_commands(ptr: *mut u8) -> usize {
    let mut offset = 0;

    // Command 1: Create a DIV
    *ptr.add(offset) = CMD_CREATE_ELEMENT;
    offset += 1;
    // (Here you'd encode "div" with null termination)

    // Command 2: Set text
    *ptr.add(offset) = CMD_SET_TEXT;
    offset += 1;
    // (Encode the text to insert)

    offset // Return how many bytes the command buffer is
}

JavaScript side:

const len = wasm.instance.exports.generate_ui_commands(ptr);
const commands = new Uint8Array(wasm.instance.exports.memory.buffer, ptr, len);

let i = 0;
while (i < len) {
    const opcode = commands[i++];
    if (opcode === 1) { // CMD_CREATE_ELEMENT
        // Read string from memory and call document.createElement()
    } else if (opcode === 2) { // CMD_SET_TEXT
        // Read string and call node.textContent = ...
    }
}

WASM writes this command buffer into linear memory. JS reads it in a single pass and executes each command against the DOM. One boundary crossing for an entire tree of DOM mutations.

This is conceptually identical to how GPUs work: Vulkan and Metal use command buffers because the CPU↔GPU boundary has overhead similar to the JS↔WASM boundary. You record commands, then submit the buffer.

When to use it: UI frameworks written in WASM that need to manipulate the DOM. Any scenario where WASM needs to fire complex sequences of JS operations.

The tax: You're designing a mini VM / bytecode interpreter on the JS side. Debugging is harder — you're staring at opcode streams instead of function calls. The command buffer format becomes an API contract that's painful to change.

---

Pattern 12: Ring Buffer (Circular Buffer)

A fixed-size buffer in WASM's linear memory with two pointers:

Rust side:

const BUFFER_SIZE: usize = 1024;
static mut RING_BUFFER: [u8; BUFFER_SIZE] = [0; BUFFER_SIZE];
static mut HEAD: std::sync::atomic::AtomicUsize = std::sync::atomic::AtomicUsize::new(0);

#[no_mangle]
pub extern "C" fn produce_data(data: u8) {
    unsafe {
        let current_head = HEAD.load(std::sync::atomic::Ordering::Relaxed);
        RING_BUFFER[current_head % BUFFER_SIZE] = data;
        HEAD.store(current_head + 1, std::sync::atomic::Ordering::Release);
    }
}

JavaScript side:

// JS acts as the consumer (e.g., in an AudioWorklet)
let tail = 0;
const headPtr = wasm.instance.exports.get_head_pointer();
const ringBuffer = new Uint8Array(wasm.instance.exports.memory.buffer, bufferPtr, 1024);

function consume() {
    const currentHead = readIntFromMemory(headPtr);
    while (tail < currentHead) {
        const data = ringBuffer[tail % 1024];
        processAudio(data);
        tail++;
    }
}

The producer (WASM) advances the head pointer after writing data. The consumer (JS, or a Web Worker) advances the tail pointer after reading. When head reaches the end of the buffer, it wraps around to the beginning.

For a single-producer, single-consumer scenario, this is lock-free by design: the producer only writes head, the consumer only writes tail. No mutexes, no atomic CAS, no contention.

A notable variant is the BipBuffer (bipartite buffer): it guarantees that written data is always in a contiguous block, even when wrapping around the buffer boundary. This matters for WASM because you can pass a single pointer+length to describe the readable region, without the consumer needing to handle two disjoint segments.

When to use it: Audio processing (AudioWorklet + WASM), real-time telemetry, video frame pipelines — any producer-consumer streaming scenario.

The tax: The fixed buffer size means you must handle the "buffer full" case (discard data, block, or grow). Not suitable for bursty workloads where data volume is unpredictable.

---

Pattern 13: Double Buffering

Two identical buffers. WASM writes to Buffer A while JS reads from Buffer B. When WASM finishes writing, the buffers swap roles.

Rust side:

static mut BUFFER_A: [u8; 800 * 600 * 4] = [0; 800 * 600 * 4];
static mut BUFFER_B: [u8; 800 * 600 * 4] = [0; 800 * 600 * 4];

#[no_mangle]
pub unsafe extern "C" fn render_frame(use_buffer_a: bool) -> *const u8 {
    let buffer = if use_buffer_a { &mut BUFFER_A } else { &mut BUFFER_B };
    // Compute physics and write pixels to the active buffer...
    buffer.as_ptr()
}

JavaScript side:

let usingBufferA = true;

function loop() {
    // Rust writes to Buffer A while JS reads and paints the previous frame (Buffer B)
    const ptr = wasm.instance.exports.render_frame(usingBufferA);
    const view = new Uint8ClampedArray(wasm.instance.exports.memory.buffer, ptr, 800 * 600 * 4);

    ctx.putImageData(new ImageData(view, 800, 600), 0, 0);

    // Swap buffers for the next frame
    usingBufferA = !usingBufferA;
    requestAnimationFrame(loop);
}

Zero contention, zero locks. The consumer always reads a complete, consistent snapshot. The producer never stalls waiting for the consumer.

This is the standard technique in game rendering (front buffer / back buffer) applied to the WASM boundary. Combined with requestAnimationFrame, you get a smooth pipeline:

1. WASM computes frame N+1 in Buffer A
2. JS renders frame N from Buffer B using putImageData or texImage2D
3. Swap
4. Repeat

When to use it: Rendering pipelines, any scenario where production and consumption need to be decoupled and never block each other.

The tax: Double memory usage. You need a coordination mechanism to signal when swapping is safe (can be as simple as a flag in shared memory or a postMessage to a Worker).

---

Pattern 14: SharedArrayBuffer + Atomics

The only way to achieve true shared-memory concurrency in the browser with WASM.

A SharedArrayBuffer is a block of memory that multiple Web Workers (and WASM instances) can read and write simultaneously. Combined with Atomics (wait, notify, compareExchange), you can build any concurrent data structure — lock-free queues, mutexes, semaphores.

// Main thread
const shared = new WebAssembly.Memory({
    initial: 256, maximum: 256, shared: true
});

// Worker can access the same memory
worker.postMessage({ memory: shared });

// WASM in the worker writes data
// Main thread reads it via Atomics.load / Atomics.wait

This enables patterns that are impossible otherwise: a WASM physics engine running in a Worker, updating shared state that the main thread's renderer reads every frame. No postMessage serialization, no copies.

The critical restriction: Requires Cross-Origin Isolation (Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp headers). This is a post-Spectre/Meltdown security requirement that breaks many third-party embeds (ads, analytics, iframes).

When to use it: Multi-threaded WASM applications, parallel processing, any scenario where data is too large or updates too frequently for postMessage.

The tax: Cross-Origin Isolation requirements can be a deployment blocker. Concurrency bugs (races, deadlocks) are just as real here as in any shared-memory system. The Atomics API is low-level and easy to misuse.

---

Pattern 15: The Async Boundary — JSPI (JavaScript Promise Integration)

Every pattern so far assumes synchronous execution: WASM calls JS, JS returns immediately. But the web is asynchronous. fetch(), IndexedDB, setTimeout, Web Crypto — they all return Promises.

Before JSPI, you had two terrible options:

a) Asyncify — A compile-time transformation that instruments your WASM binary to capture and restore the entire call stack, simulating suspension. It works, but bloats binary size by up to 50% and adds overhead to every function call (even synchronous ones).

b) Restructure your code — Rewrite your synchronous C/Rust code to be callback-oriented, with explicit state machines. Possible, but it destroys code structure and developer experience.

JSPI is the real solution. It's a proposal (available in Chrome behind a flag, actively being standardized) that lets a WASM function:

1. Call a JS imported function that returns a Promise
2. Suspend WASM execution
3. Return a Promise to JS
4. Resume WASM execution when the Promise resolves

From WASM's perspective, the call looks synchronous. From JS's perspective, it's just a Promise. The engine handles stack suspension and resumption with zero instrumentation overhead.

// JS side: wrap an async import with JSPI
const importObj = {
    env: {
        fetch_data: WebAssembly.promising(async (url_ptr, url_len) => {
            const url = decodeString(url_ptr, url_len);
            const response = await fetch(url);
            return writeToMemory(await response.arrayBuffer());
        })
    }
};

When to use it: Any WASM application that needs to call asynchronous Web APIs — network requests, file access, crypto operations, timers.

The tax: Browser support is currently limited (Chrome with flag, Firefox in progress). Requires understanding the suspension model. Not all code patterns are compatible (you can't suspend across certain boundaries like WASM→JS→WASM re-entry).

---

Epilogue — The Component Model: The Pattern That Wants to Rule Them All

Every pattern in this article exists because core WebAssembly's type system only speaks numbers. Strings? Pointer+length hack. Structs? Manually encoded in linear memory. Objects? Opaque handle workaround. Async? Stack manipulation hack.

The WebAssembly Component Model asks a radical question: what if the runtime handled all of this?

The core idea

The Component Model introduces three things on top of core WASM:

1. WIT (WebAssembly Interface Types) — An IDL (like Protobuf or OpenAPI) that describes component interfaces in terms of high-level types:

package myapp:image-processor;

interface processor {
    record image {
        width: u32,
        height: u32,
        pixels: list<u8>,
        format: pixel-format,
    }

    enum pixel-format { rgba, rgb, grayscale }

    apply-filter: func(img: image, filter: string) -> result<image, string>;
}

world image-app {
    export processor;
}

Strings, lists, records, enums, results, options — all first-class types, defined once, understood by every language.

2. Canonical ABI — A precise specification of how each WIT type maps to bytes in linear memory. A string is always UTF-8 with a specific pointer+length layout. A record has deterministic field ordering and alignment. A list<u8> has a concrete binary representation.

This is essentially Pattern 2 (pointer+length) and Pattern 8 (format-aligned layout) elevated to a universal standard. The toolchain generates the serialization code — you never see it.

3. Components — WASM modules wrapped with metadata that declare their imports and exports in WIT terms. They're self-describing: you can inspect a .wasm component and know its complete interface without any external documentation.

What it makes unnecessary

The Component Model subsumes nearly every pattern in this article:

Pattern	How the Component Model absorbs it
Pointer + Length	The Canonical ABI handles it automatically
wasm-bindgen glue	wit-bindgen generates equivalent code from WIT
Typed Array Views	The runtime can optimize data transfer internally
String passing	The Canonical ABI defines UTF-8 encoding; the runtime can optimize transcoding
Format-aligned zero-copy	The Canonical ABI is the aligned format
externref	The Component Model has its own resource handles
Function tables	Exports and imports are rich types

Composition: the real superpower

Beyond type marshaling, the Component Model enables composition — linking components written in different languages into a single application:

# A Rust parser + a Python data processor + a Go HTTP server
# composed into a single .wasm with no network boundaries
wasm-tools compose parser.wasm processor.wasm server.wasm -o app.wasm

No serialization between components. No shared memory management. No IPC. The runtime links them through the Canonical ABI at instantiation time. A function call between components looks and costs like a normal call.

Worlds: capability-based security

A World defines what a component can see — which interfaces it can import and export. A component built for the wasi:http/proxy world can handle HTTP requests but cannot access the filesystem. A component in the wasi:cli/command world can read files but cannot listen on sockets.

This is the security model that containers wish they had. Instead of giving a process access to everything and hoping seccomp catches the bad calls, you define capabilities at the interface level. A component literally cannot call functions it hasn't declared in its world.

Where it stands today (February 2026)

Production-ready server-side: Wasmtime has full Component Model support. Frameworks like Spin (Fermyon) and wasmCloud run production workloads on it. American Express built an internal FaaS platform entirely on WebAssembly components.

Not ready for browsers: The Component Model is a W3C proposal but isn't implemented in any browser engine yet. Browser-side WASM still uses core modules with all the manual patterns described above.

WASI 0.3 is coming: It adds native async support to the Component Model, eliminating the need for JSPI/Asyncify in server-side contexts. The async model avoids the "function coloring" problem — async imports plug seamlessly into synchronous exports without requiring downstream rewrites.

Threading is the gap: Shared-memory concurrency between components isn't supported yet. For compute-intensive parallel workloads, you still need SharedArrayBuffer and manual coordination.

The bottom line

The Component Model is to our 16 patterns what a managed runtime is to manual memory management. It aspires to absorb the complexity, standardize the solutions, and let the toolchain and runtime do the dirty work.

But — and this is important — understanding the patterns remains essential:

1. In the browser, they're all you've got. The Component Model isn't coming to browsers anytime soon.
2. For hot paths, manual control wins. Just as you sometimes skip the ORM and write raw SQL, you'll sometimes skip wit-bindgen and reach for a ring buffer or command buffer for performance-critical code.
3. The Component Model uses these patterns internally. The Canonical ABI is pointer+length with format-aligned layout. Understanding the foundations makes you a better systems developer, even when the abstraction handles it for you.

That's the abstraction tax in a nutshell: you can pay it automatically and accept the default cost, or you can understand the underlying patterns and choose exactly how much to pay.