Ben Smith, chair of the WebAssembly community group, recalled at the WebAssembly Summit the beginnings of WebAssembly, and discussed how it has increased and refined its scope and capabilities.
Smith started by looking enthusiastically at the audience, reminiscing that:
5 years ago, WebAssembly literally did not even exist.
Back in 2013, Google's NaCL technology already allowed compiling C/C++ programs to run natively sandboxed in the Chrome browser. Alon Zakai, who founded emscripten in 2010 and co-created WebAssembly and asm.js, provided concrete evidence that C and C++ programs could be ported to any web browser thanks to emscripten and asm.js.
In April 2015, several developers came up with both an executable binary and textual format for WebAssembly. At the time, the high-level Wasm goals were expressed as follows:
- Define a portable, size- and load-time-efficient binary format to serve as a web compilation target
- Define a human-editable text that is isomorphic and convertible to/from the binary format
- Design v.1 to allow an effective (load-time and performance) polyfill via client-side compilation to asm.js
- Design v.1 as Minimum Viable Product basically what you can do with asm.js
- Design to integrate well with the existing web platform […]
- Design to maintain the versionless, feature-testing and backwards-compatible evolution story of the web; […]
- Design to allow execution in non-browser environments
Thus, goal number one was to be a compilation target, and the second was to do no more than match the ability of asm.js, e.g. allow C and C++ software to be run as web applications at a good speed. Smith noted that this rather limited goal was essential to get people on board. The original creators knew they wanted to run in non-browser environments, but the original goal was simply to design to allow such execution, leaving out of scope the details of how that would eventually get done.
From these initial goals, WebAssembly has been growing and refining its scope and specifications. Smith aggregated that evolution into a pie metaphor, inspired by the acronym A.P.I.E., standing for Abilities (what can Wasm do?); Producer (who can make Wasm?); Interoperability (who can Wasm talk too?); Embedder (What can use Wasm?). Smith spent the rest of the presentation showing how these four categories have accumulated more WebAssembly language proposals over time, thus metaphorically expanding the pie.
In November 2017, WebAssembly added garbage collection (Ability and Producer categories of the APIE framework) and host bindings as desired features in the Interoperability capability. In 2018, the Wasm C API was added to the Embedder category. In August 2019, typed function references joined the Ability category, while type imports, WebAssembly System Interface (WASI), and interface types joined the Interoperability category:
Those new proposals fed from previous work on garbage collection and host bindings, and experience with compiling higher-level languages to WebAssembly. The host bindings proposal for instance no longer exists and has been subsumed by the interface types proposal. The pie has grown today to the point that WASI and interface types have their own groups or subgroups. Other initiatives such as SOIL (Single Open Intermediate Language) have also been spurred from the growth of WebAssembly.
The WebAssembly: Expanding the PIE full talk can be accessed on the Summit’s website, and contains extra technical details, historical perspectives, and illustrations.
The WebAssembly Summit was held in Silicon Valley, on the 10th of February 2020. The WebAssembly Summit is a one-day, single-track conference about all things WebAssembly.