Discover more from Matt Rickard
WASI vs. WASM
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?