The Promise of Wasm off the web
The Promise of Wasm off the web
While the name might not reflect it, one of the original goals of Web Assembly was to not be tied directly to the web.
Off the web?
- Wasm is just a bytecode
- Already embedded in many places
- Sandboxed Memory
Use Case: MDBook
- Static Site Generator
- Candidate: Plugin System
- Uses Pipes to pass JSON between processes
- Executes plugin twice
- Once with argument for renderer
- Once with JSON of Book
Issues
- Plugins need to be compiled for arch
- User's need to know these details
- JSON can get pretty big
Possible Solution
- MDBook could host a WASM Runtime
- This could be used to execute plugins
- Wasm API
- Expose 2 function
- 1st Takes renderer string returns bool
- 2nd Takes Book returns modified Book
- Expose 2 function
- Helpers?
Benefits
- Plugin developers compile once
- May not require serialization
- Controlled system access
- Less end-user knowledge
Existing Runtimes
- Wasm Micro Runtime (Intel)
- Embedable with C API
- Wasmer (Wasmer.io)
- Packages to embed in Rust, C/C++, Python, Go, PHP, Ruby, C#, R & Swift
- Lucet (Fastly)
- System Runtime (Not embedable)
- Wasmtime (Mozilla? CraneStation)
- Possibly embedable in Rust
WASI
Web Assembly System Interface
- Like Web APIs but for non-web environments
- Or POSIX for Wasm
Pending Proposals
- Reference Types
- External Reference Types
- Multi-Value
- Multiple Return Values
- GC
- Optional GC Support
- Interface Types
- WebIDL