Wasm

What languages are supported in WebAssembly running outside the browser? This is a question I often hear people ask. It’s has a complicated answer because:

1. WebAssembly outside the browser needs WASI and not all languages have WASI support in their toolchain.
2. Even if WASI is supported well in a language, WASI has its own limitations that you need to take into account.

In short, you can’t take any code written in any language and expect to compile and run it as a Wasm+Wasi module right now. Documentation on what’s supported is patchy or misleading at times. Unfortunately, you often need to try things out before knowing what works and what doesn’t.

In my previous posts, I talked about how you can run WebAssembly (Wasm) outside the browser with Wasi and run it in a Docker container with runwasi. The Wasi specification allows Wasm modules access to things like the filesystem and environment variables (and I showed how in this blog post) but networking and threading are not implemented yet. This is severely limiting if you want to run HTTP based microservices on Wasm for example.

Docker recently announced experimental support for running Wasm modules (see Announcing Docker+Wasm Technical Preview 2). In this blog post, I explain what this means and how to run a Wasm module in Docker.

Why run Wasm in a container?

In my Exploring WebAssembly outside the browser post, I mentioned how Wasm is faster, smaller, more secure, and more portable than a container. You might be wondering: Why take something faster, smaller, more secure, and more portable and run it in a container?

In my Exploring WebAssembly outside the browser post, I talked about how WebAssembly System Interface (WASI) enables Wasm modules to run outside the browser and interact with the host in a limited set of use cases that Wasi supports (see Wasi proposals).

In this blog post, let’s look into details of how to compile code to a Wasm+Wasi module and then run it in a Wasm runtime. Notice that I use Wasm+Wasi module deliberately (instead of just Wasm) because some languages have Wasm support and can run perfectly fine in the browser but they have no or limited Wasi support to run outside the browser.

Introduction

WebAssembly (Wasm) was initially designed as a binary instruction format for executing native code efficiently within web browsers. The original use cases are focused on augmenting Javascript in the browser to run native code in a fast, portable, and secure way for games, 3D graphics, etc.

However, its potential extends far beyond the browser. In this blog post, we’ll delve into the exciting realm of running Wasm outside the browser, exploring its advantages, and relevant specifications.