JSPI for WebAssembly

JSPI for WebAssembly

JavaScript Promise Integration lets WebAssembly cross an async JavaScript boundary without turning your wasm-facing API into a pile of manual continuation logic. That is the key reason JSPI is an Interop 2026 focus: it removes friction from a real production pattern.

const imports = {
  env: {
    fetchText: new WebAssembly.Suspending(async (urlPtr) => {
      const url = readString(memory, urlPtr);
      return await fetch(url).then((res) => res.text());
    }),
  },
};

const { instance } = await WebAssembly.instantiateStreaming(fetch('/app.wasm'), imports);
const run = WebAssembly.promising(instance.exports.run);
await run();

What JSPI Fixes

Without JSPI, an async JavaScript import often forces you to split control flow manually or redesign the wasm surface around callbacks and polling. JSPI keeps the boundary closer to normal function calls while still preserving promise-based suspension under the hood.

Good Use Cases

This is most useful when wasm occasionally needs network, storage, or host-provided async services but the main computation still belongs inside the module. It is not a reason to push every DOM concern into wasm.

Keep the Boundary Narrow

Batch host calls, move large payload marshaling out of hot loops, and keep rendering orchestration on the JavaScript side. JSPI makes async boundaries nicer, but it does not make boundary crossings free.

Rollout Strategy

Feature-detect WebAssembly.Suspending and WebAssembly.promising, then fall back to an explicit async wrapper when they are missing. That keeps your wasm API stable while browser support catches up.

---