WebAssembly runtimes overview - intro

Write once, run anywhere - the Holy Grail of Portability

Since long time ago, one of the holy grails of computing is portability. In the 90's Java promised, "write once, run anywhere (WORA)". But while you could do that with simple programs, you probably would quickly start fighting the details of the different OS's, devices, versions, you had to run. WORA then quickly becomes WODE (Write Once, Debug Everywhere). Another issue is that you would end up depending on the JVM being available on the target and having to program mainly with just Java or other JVM languages like - at the time - Groovy, JRuby, etc.

Fast forward to the 2010s, and another "Java" - I know, I know - is what had got us the closest to the WORA world so far. Javascript slowly overcame some hurdles from being something like a joke to become a - slightly more - respectable language and the universal programming language of the Web.

But we are still kinda tied to a single language. Transpilers try to mitigate this issue but you could need to develop systems for the Web in other programming languages completely different from JavaScript, to reuse existing components, for example.

Enter WebAssembly

All this led to the creation of WebAssembly. It is a compact binary format aimed at fast execution and small binaries sizes. Like Javascript, it runs sandboxed, providing security features that allow running code from the Web without - mostly - putting your system at risk. It already allows running C, C++, Rust and many other languages (thanks, LVVM) "anywhere".

The quotes are because, unfortunately, there is still the issue of dealing with the details of where you run. To try to reduce this task, there is an ongoing work to standardize the basic operations in a system interface (WASI).

So, what now?

Sometimes you need portability without all the bloat of HTML/CSS/JS parsing/rendering/etc. This led to the creation of platforms like Docker, where you could reuse the software from practically any language and run anywhere you had the docker engine running.

While the main showcase of WebAssembly initially was the web browser, there is new exciting work on using it outside it too. Like Solomon Hykes (of docker itself) said:

Solomon Hykes

@solomonstre

If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! twitter.com/linclark/statu…

20:39 PM - 27 Mar 2019

Lin Clark @linclark

WebAssembly running outside the web has a huge future. And that future gets one giant leap closer today with... 📢 Announcing WASI: A system interface for running WebAssembly outside the web (and inside it too) https://t.co/HdEAZAyqYu

694 1691

This series of posts is intended to be a quick overview of some of the main tools that allow running WebAssembly outside the browser.

The initial list of runtimes we'll be checking:

• Wasmer
• Wasmtime
• Lucet
• Wasm micro runtime
• Wee8

We'll cover the scenarios each runtime tries to address. From running standalone wasm binaries to embedding the runtime into an actual application.

A more extensive list of WebAssembly runtimes can be found on Github.

So, on to the runtimes.