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?