WASI vs. WASM

Sep 5, 2022

WebAssembly (WASM) modules have no conception of the filesystem, the network, or much else outside the browser sandbox. Many are experimenting with using the format outside the browser for server-side applications. How can it be used both serverside and clientside?

WASI is the WebAssembly System Interface. It was designed to make WebAssembly modules easy to use in non-browser environments. Its scope includes

  • APIs for host filesystems, network stacks, and other resources.
  • APIs for graphics, audio, input devices
  • APIs for encryption, format conversion, and other transformations (particularly where hardware acceleration may be available on some platforms)

Can WASM/WASI serve two masters: web-first and server-first?

Adding WASI to the WebAssembly target creates some problems:

  • Larger binary sizes for unnecessary features (when the module runs in the browser)
  • Concepts that don't map cleanly to the browser sandbox
  • Overlap with existing Web APIs

Can it be done in a way that doesn't fragment the toolchain, developers, and userbase? Will WASI targets be as portable? Is it a technology problem or a standards problem?