The tug-of-war over server-side WebAssembly

submited by

Style Pass

2023-03-24 12:30:08

One side embraces the idea that Wasm was designed in the context of a broader web platform. Their approach to running Wasm outside of the browser is to transplant relevant parts of the web platform onto the server, and run Wasm within this browser-like context.

The other side sees Wasm as a CPU-independent bytecode, for which the browser is just one use case. Their approach is to standardize a syscall-like interface (WASI), akin to the one an operating system provides to native code.

The source of the rift is that Wasm doesn’t specify a particular interface with the outside world, by design. While Wasm itself is portable across platforms, it’s only really useful when paired with such an interface.

Although both sides generally imagine the industry converging on common standards so that code is interoperable between platforms, they are pulling towards fundamentally incompatible visions of what those common standards should look like.

Compilers that produce browser-ready Wasm generate (at least) two files: the Wasm module itself, and a JavaScript shim. The JavaScript shim implements a bespoke ABI that exposes any relevant browser APIs to the module.