Mozilla’s WebAssembly started as an experiment, almost a question: is it possible to run arbitrary code in a browser without breaking the browser sandbox? A side benefit would be faster web applications that would outperform current web technologies, allowing developers to bring existing desktop applications to the web.
It was an experiment that arrived at the right time. Microsoft was deprecating its ActiveX plug-in model, as was Google with its NaCl tools. Old web development models were rapidly disappearing, washed away by a tide of security breaches and a lack of cross-platform compatibility.
Since its initial launch, WebAssembly has been adopted by all the major browsers, with support from Mozilla, Google, Microsoft, and Apple, who’ve all contributed code.
There’s a lot to like around WebAssembly, and it’s already starting to influence thinking around popular web frameworks. Microsoft is experimenting with it as the foundation of Blazor, an in-browser extension of its ASP.NET Core application platform.
Experiments with WebAssembly outside the browser are all very well, but if it’s going to be a tool that supports cross-platform as well as cross-browser development, it needs to have new standards built around it. Mozilla recently announced the start of such an effort, with the first release of WASI: the WebAssembly System Interface.
You can perhaps consider WASI as the boundary between system level code running on the host platform and applications running in user mode.
A systems interface like WASI is a fundamental operating system concept. It’s how our applications use system calls, for example reading and writing files in a protected manner. The OS is protected from memory errors, and applications can guarantee that a read or a write can’t be corrupted by another application, or that the results of one call won’t be delivered to another application making the same call. You can perhaps consider WASI as the boundary between system level code running on the host platform and applications running in user mode.
A service like Lucet is an important tool for edge compute. Developers can write code in their language of choice, compile to WebAssembly, and then run at near-native speeds without having to know anything about the architecture of the underlying edge service. It also allows service providers to use heterogeneous hardware to roll out appropriate compute servers for location and for load. For example, ARM servers could be deployed where power is an issue, with Intel or AMD for more heavy duty workloads. There’s also the opportunity for a service provider to use it to experiment with alternative platforms, like RISC-V or Power, without disrupting workloads.