WebAssembly -- A Primer

For more similar content, follow along at cloudconstructed.substack.com, or on Twitter @samecrowder.

In December 1990, Tim Berners-Lee released the first internet browser, which was called?WorldWideWeb. The internet had been around since 1983, but there was no application that made its contents (i.e. web pages) accessible to the average person. A few years later, Marc Andreessen’s?Mosaic?was released as a more user friendly and easy to install alternative to earlier browsers like WorldWideWeb, and its release is often cited as a spark for the internet boom of the 1990’s.

In the the early days, the web was comprised of static content: text files with a sprinkling of design and coloring. Browsers only needed to make it easy to search the web for this content and display it. Fast forward to today, and modern browser-based apps make it possible to design a home, navigate the globe, edit high-def video, and more. Along the way, browsers have been tasked with not only making it simple and easy to navigate content, but also with vastly increasing their computational horsepower.

The Browser Gets Beefier

In 1994, the Mosaic browser required a minimum of only?4 MB?of memory to run on Mac systems. Today’s Macbooks commonly have 2,000 to 4,000 times more memory, as anyone familiar with?Moore’s law?could tell you. As personal computers have drastically increased in compute and memory capacity, web browsers have grown in their memory and cpu requirements both because they can and because the nature of modern applications has made it a necessity.

Running Google Chrome today with 20 tabs open can use up to?1.8 GB?of memory. Obviously browsers have become more powerful and resource-hungry over time as systems have allowed it and apps have mandated it. At a certain point, browser-based apps meet a natural threshold where continuing to throw money at performance problems is no longer the most effective option. Some sort of rearchitecting at a system level is necessary to give these apps performance as though they are directly running on the operating system.

asm.js Has Entered the Chat

In 2013, Mozilla introduced asm.js, which allows developers to write code in C/C++ and?transpile?it to javascript and integrate it into browser applications. With asm.js, web developers get the performance advantages of these lower-level languages, like manual memory management and compilation-time optimizations. While asm.js enabled better performance and C/C++ portability, it had its drawbacks including the need to transfer full-fledged javascript?over the wire?and the tight coupling of the language subset to its parent.

After its release by Mozilla,?asm.js?had its?four years?in the sun, but the release of?WebAssembly?in 2017 quickly led to its deprecation. WebAssembly provided a superset of the features of asm.js, with the added benefits of further improved performance and language-agnostic portability. I’d like to consider the implications of this new technology in the browser, but also far beyond.

Introduction to WebAssembly

WebAssembly (often referred to as ‘wasm’) began as a way to run portable code in the browser with near-native performance. Near-native performance means that the application is almost as fast as low-level languages like C/C++ running directly on the host operating system, as opposed to javascript which runs in the sandboxed environment of the web browser. Javascript is a human readable language was decent performance characteristics, but WebAssembly disregards human readability to place its focus solely on performance. WebAssembly is a language in a sense, but at a lower level it’s really a binary format and a compilation target.

Other human-readable programming languages compile down to WebAssembly (e.g. C++ / Rust / Go), and the resulting machine code is executed directly on the hardware. This compilation process is what provides the performance benefit, but it also provides the benefit of language portability. Now that all major browsers ship with WebAssembly runtimes, any language that can compile to the WebAssembly target can run in the browser. Developers love this flexibility when building performant, browser-native applications. Additionally, a?whole universe?of open-source code (e.g. C++ libraries maintained over decades) can now be run in the browser, unlocking a lot of new functionality.

The Evidence of Performance

A few well-known, computationally intensive programs have been migrated to use WebAssembly and have become faster because of it. For example,?Figma?migrated its browser-based prototyping and graphical editing tool to use WebAssembly for its core rendering engine and?decreased?the page load time by 70%. Figma previously used asm.js (before WebAssembly existed) for similar performance reasons.

Another example, the web version of?AutoCAD?also runs on WebAssembly. WebAssembly is not meant for all browser-based computing needs. For example, it doesn’t have access to the DOM (document object model) APIs, and it needs to communicate with javascript for anything involving the DOM. It is purpose built for heavy mathematical tasks, or number crunching.

Browser Breakout

If you are building a language-agnostic compilation target meant to run in all types of browsers and execute machine code at a low level, you’ll need to support a vast array of operating systems and CPU architectures. I’ll never forget the frustration of completing C++ projects in college that would run perfectly against the test driver on my laptop, but then failed on a few cases when running against the same driver on the school’s Linux machines. Low-level languages provide APIs to interact with hardware (e.g. memory management) which means that the type of hardware they run on matters.

The beauty of WebAssembly is that its binary format was designed to run efficiently on a?multitude?of CPU architectures and operating systems. This initially enabled the support of WebAssembly across all major browsers, but it has even greater implications for?edge computing?and the server side. Such a universal compilation target allows you to write code once (in any language) and run it virtually anywhere, which edge computing requires given the high number of devices on which apps run and the variety of machine types.

Some of the biggest names in edge computing, Fastly and Cloudflare, have integrated WebAssembly as a core piece of their edge infrastructure due to this. In Fastly’s?Compute@Edge?platform, customer code in most any language is?ahead-of-time compiled?to WebAssembly. With this code, customers define functions with modular, lightweight pieces of logic that need to be run in close physical proximity to users. On a per request basis, WebAssembly?modules?are instantiated, and a function is run. In this kind of a model, programmers think only in terms of their core, distributed application logic (in any language!). The compilation target is provided to them by the open-source community and the server machines by the edge provider.

Similarly, Cloudflare’s?Workers?platform added WebAssembly support (previously they only supported javascript) in 2018 to give their users (a) near-native performance and (b) language-agnosticism. WebAssembly has a clear value add on the server-side to compliment its browser-based heritage.

Enhanced Security via Sandboxing

An ancillary (or some may argue, core) benefit to WebAssembly is its deny-by-default security posture, which stems from its heritage as a browser-first tool and the nature of javascript. Javascript was built to be sandboxed to protect users from malicious websites accessing and manipulating system resources. If javascript by default had access to, say, a host machine’s file system, it could copy / move / delete files at will. For this reason, javascript was built in a?sandboxed environment?without these permissions.

WebAssembly adheres to a security paradigm known as?capability-based security. With capability-based security, processes are granted permission to perform actions based on explicit tokens, or keys, granted to them by the host entity. Without explicit permissions, requests are denied by default. Commonly, IoT and other edge devices adhere to network driven security, in which requests are denied or accepted at the individual request level based on static permissions. This paradigm still allows malicious programs to, for example, create lots of external network connections before being denied, which could have adverse effects. Sandboxing is a more powerful security posture.

Evangelists in the space have even argued that WebAssembly could?replace Kubernetes?as the go-to method of application orchestration and deployment. You could imagine that instead of shipping containerized versions of services, you could simply ship WebAssembly modules, which are?smaller to transmit?over the wire and faster to spin up. These claims are hopeful at best, as WebAssembly modules don’t really map to containers in an app orchestration analogy, but are more like a combination of?processes?using private namespace.

The WebAssembly Universe

Tracing the WebAssembly dev lifecycle from human-readable code to applications (similar to my recent?article?about tools across the dev lifecycle), there are compilers, runtimes and higher-level tools. Compilers take code in most any programming language and translate it to machine code, optimizing along the way.?Emscripten?is the most popular compiler for C/C++. Rust is compiled to WebAssembly with a?compiler?of the same name.?TinyGo?is used for Golang.

Runtimes are programs which provide environments and execution logic to run WebAssembly modules on hardware. Popular runtimes include?wasm3,?wasmer,?pywasm, and?wasmtime. Some runtimes emphasize universal performance across hardware types, while others focus on security of the sandboxed environment. Higher up the stack, tools like?vecty,?WasmCloud, and?WasmEdge?can be used as frameworks for building WebAssembly based applications, on both the client and server side.

Commercializing WebAssembly

With the potential that WebAssembly has to redefine how software gets built, I’m excited as an investor to continue following the space. With that said, early commercialization efforts of the technology have been slow. While an abundance of open-source technologies exist and have active communities, I was only able to find five companies commercializing WebAssembly. The first is?Wasmer, the developer of the OSS runtime mentioned above.?Cosmonic?is the developer of WasmCloud, which is a distributed platform for writing logic to run anywhere on the edge, leveraging WebAssembly’s secure by default posture.

Suborbital?allows to developers to build customizable products with an embedded editor in which end users can write code that compiles to WebAssembly and is executed server-side. Finally,?Second State?develops the WasmEdge runtime and aims to reduce the complexity and increase the velocity of app dev at the edge.

With low-level technologies like these, the fundamental question is the ability for companies to commercialize on adoption. The challenge can be capturing value from something so fundamental to building software. As an example, look at?Docker?as an open-source technology and as a company. In 2013, Docker was released as a containerization technology making it easier to package and run applications across operating systems.

Docker swept across the developer landscape like wildfire, but the business behind it struggled to find an effective go-to-market strategy. Now similarly with WebAssembly, open-source compilers and runtimes have been widely adopted, but no companies have yet been built around the technology. I will keep my eye on this space in coming years, both as an investor and as a fan of open source!