Bytecode Alliance Lays Out Plans for WebAssembly on the Server-side – InfoQ.com

At Bytecode Alliance's first anniversary, WebAssembly developers Lin Clark and Till Schneidereit announced in a blog post that Fastly has acquired part of the WebAssembly (Wasm) team from Mozilla. Going forward, Mozilla will continue to focus on Wasm-in-the-browser, especially in the Firefox browser. Fastly, on the other hand, will take stewardship within Bytecode Alliance for Wasm-on-the-server, including Fastly's own commercial WebAssembly serverless offerings Compute@Edge. That arrangement also resulted in the merger of Mozilla's wasmtime and Fastly Lucet Wasm VM projects. Lucet and wasmtime already share many codebases, and this merger ensures that their future developments will continue on the same path.

In the blog post, Clark and Schneidereit laid out their technology vision for the future of Wasm-on-the-server. Core to their vision is the nanoprocess model, which provides a secure and lightweight container for Wasm programs yet still makes it easy for sandboxed Wasm programs to communicate with each other and with the rest of the system.

Technically, there are three proposed enhancements to Wasm on the critical path to the nanoprocess.

The first enhancement is the WebAssembly Systems Interface (WASI), which provides a way for Wasm programs to call standard libraries functions in the host system. On the server-side, it means access to the file system, environment variables, random numbers, and sockets. WASI is now supported across multiple leading Wasm implementations.

WASI implementations vary in their completeness and performance. For example, Google's V8 uses the host environment's JavaScript runtime as a proxy for operating system access and hence is slow.

The WASI approach is not limited to operating system standard library access. The blog post discussed additional WASI-like extensions Bytecode Alliance is championing, such as wasi-socket and wasi-nn. Beyond the Bytecode Alliance, there are also many initiatives to give Wasm access to more host functions. For example, in the blockchain world, the Ethereum flavored WebAssembly (Ewasm) is a form of WASI that gives Wasm access to the host Ethereum blockchain's user accounts and transaction services.

The second enhancement is the Interface Types proposal, which enables Wasm programs to communicate with external programs, either in the host operating system or in the language runtime that embeds Wasm (eg, Node.js). This proposal is still in its early stage and does not yet have support from the compiler toolchain. However, it is already supported in wasmtime and Second State VM. The goal is to make Wasm programs more powerful and more embeddable.

Taken together, WASI and Interface Types make it easy for developers to fully take advantage of the native host system while preserving the security of the Wasm sandbox. An early example is Second State VM's work on providing native GPU access to its Wasm programs for tensorflow model inference.

The third element of the nanoprocess is module linking, which allows Wasm programs to call each other in addition to calling host functions. The ability to declare module dependencies could enable public package management systems similar to Node.js's NPM and Rust's Crate.io. It could complement the WAPM work Wasmer already started.

This latest blog post see Bytecode Alliance laying out a concrete vision for wasm-on-the-server. At the same time, the Wasm open-source community is now much larger than the corporations in Bytecode Alliance alone. There are multiple Wasm VM implementations, complier toolchains for programming languages, as well as host Operating Systems and environments (e.g., Node.js, Deno, or blockchains).

View post:
Bytecode Alliance Lays Out Plans for WebAssembly on the Server-side - InfoQ.com