Running down — WebAssembly 101

Jacek Sroga
Sigma IT Poland
Published in
5 min readJan 22, 2020

The WebAssembly standard is a new, high-performance, portable binary language created by experts of the World Wide Web Consortium (W3C). It can be used to build and run native applications on the web. Because it can run on many machines, the WASM is gaining popularity among software developers. At its core, the spec states that WebAssembly is a low-level language that makes it possible to run a significant part of the core logic in your web apps.

I was lucky to be involved in the WebAssembly music web project — Soundation. We have been playing and working with the WebAssembly for over a year now. In this blog post I’m going to explain how WebAssembly app can be developed, the challenges we experienced, how to create ‘hello-world’ app, and finally use cases of this technology.

Overview

WebAssembly consists of a set of instructions that are compiled to machine code by the LLVM. Because the instruction set is in machine code, the compiled code is efficient. Output files come in two different formats that contain a list of S-expressions:

  • .wasm files contain binary instruction code
  • .wat files are WebAssembly text format

The browser is expecting to load .wasm files where .wat files serve the purpose of debugging and an intermediate form designed to be exposed in text editors and browser developer tools. There is no external compiler or linker to install on the virtual machine. It’s purely client-side. The entire module is executed on-the-fly from the VM, so everything is done in the browser. You can even build custom modules using the WebAssembly and re-use them as the basis for your application.

Most common compliers

The way of instantiating the WASM module in the browsers may vary by the compiler you choose. For example, EMScripten, besides .wat and .wasm files, is generating so-called glue-js code, which you need to include on your webpage. The community already created compliers for basically every language you could use to write WASM apps.

Most popular are:

- EMScripten — The most mature environment. An LLVM-to-Web Compiler

- Blazor — Something for C# developers

- Binaryen — One of the simplest ways of compiling C++ code to .wasm.

- AssemblyScript — “Definitely not a TypeScript to WebAssembly compiler” :)

Here’s a GitHub repository where you can find much more: https://github.com/appcypher/awesome-wasm-langs

Hello World AssemblyScript Example

As an example how can we compile simple ‘add’ function I’ll be using AssemblyScript as my tool of the trade. To create our app we will need to:

  1. Write a simple AssemblyScript module and export its functions and save it as hello-world.ts
export function add(a: i32, b: i32): i32 {
return a + b;
}

2. Compile AssemblyScript (.ts) to .wasm

asc hello-world.ts -b hello-world.wasm

3. Create .html file which will include our JavaScript and load .wasm module

<!DOCTYPE html><html lang="en"> <head>  <meta charset="UTF-8">  <title>WASM Playground</title>  <script>   const wasmRequest = await fetch("./hello-world.wasm")   const wasmArrayBuffer = await wasmRequest.arrayBuffer()   const wasmModule = await WebAssembly.instantiate(wasmArrayBuffer)  </script> </head> <body></body></html>

4. Call ‘add’ function once the module is loaded

const addResult = wasmModule.instance.exports.add(5, 11);conosle.log(addResult)

Core benefits

1. It has a high performance. In addition to fast execution, WASM also has low memory usage. This is crucial for an application like DAWs, video editors, games. Due to pthreads we observed a 300% improvement of the performance when developing a new Soundation engine.

2. It’s cross-platform. WebAssembly runs on all major browsers including mobile. What’s more, there’s been started an effort of standardizing WASI — a system interface to run WebAssembly outside the web. This will allow WASM to run on embedded devices.

3. It’s open-source. WASM has been used in production for years in reach-UI applications such as Google Maps. Web app development is not profitable without a good dev team, and WASM is being developed by best dev teams that are already using it.

4. It’s sandboxed. This means that code can’t talk directly to the OS. But then how does it do anything with system resources? The host (which might be a browser, or might be a wasm runtime) puts functions in the sandbox that the code can use.

5. It’s ready for production use. Thank’s to sourcemaps supports and Chrome Dev Tools we can set up breaking points and debug low-level code which web tools.

When you should use it

Truth to be told — when building web applications, for the most cases you will not need to use WebAssembly. Simple enterprise CRUD applications can easily leverage modern JS engines and be good enough to build performant user-friendly applications.

Although for some software developers it could be music for the ears to hear they can write front-end in GO instead of JS, I don’t think that would be a good idea. Modern front-end tooling and frameworks solve problems like declarative rendering, SSR, code-splitting, different layouts modes and much more which helps to create complex and accessible UIs.

it really happened

There are cases, where having the low-level module is crucial, like for example:

  • Audio/Video editing tools (e.g. Soundation)
  • Gaming (e.g. Unity)
  • 3D graphics (e.g. Google Maps, Autocad)
  • Blockchain
  • Artificial Intelligence
  • Any kind of encryption

Use case: Soundation

Soundation it’s a digital audio workstation that allows you to create music online. When I was joining the project it was running on WebAssebly’s older brother — Google Portable Client (PnaCL). The PnaCL project was named deprecated and called to be removed from the Chrome browser soon due to security overhead. As an alternative, Google was forcing developers to move to WASM, so we didn’t have much choice.

The process of creating proof-of-concept has started. After doing a significant amount of research team has deducted that besides what WASM had to offer we need more features that were not available in Chrome yet. Most of them were in the alpha phase, but the project required all of them to accomplish glitch-free music experience.

1) Multithreading — for demanding real-time processing

2) Shared Memory (between threads — including JS main thread and AudioWrokletProcessor)

3) AudioWorklet — for glitchless rendering in a browser

Even though it was a bumpy ride we managed to deliver the world’s first DAW’s which is using WASM with pthreads. We had a pleasure to be shown on the scene during Google Dev Summit (2018) due to that accomplishment. If you are interested in the story I encourage you to watch that part of the keynote:

Summarize

WASM is not going to replace JavaScript nor is it being used on every web application. However, the development of WASM (especially when pthreads was introduced) is creating a bunch of possibilities. Ideas that suffered performance bottlenecks are now in reach. By being a highly portable standard that gained traction already, I think it’s safe to say that WebAssembly will stay in our toolkit for it’s not going to be replaced soon.

--

--