Salvation Delivered by WebAssembly (Wasm)

In this post, I'll provide a contextual overview of WebAssembly and its role in transforming web development.

You may be wary to paw through another article heralded by a headline announcing some mastermind solution to a problem so complex its nuances mere mortals can barely grasp. Christen the technology with an unpronounceable acronym and we have all the makings for a Wagnerian opera (or a technical sketch comedy, I can’t tell which). Like those fat-lady musical dramas, these long-winded articles usually require translation, program notes and three operas worth of backstory just to make sense of the thing. Reading about WebAssembly feels like watching the season finale of Game of Thrones without having seen any of the previous episodes.

So let’s try to keep things practical for our dark horse protagonist and focus on answering three questions: 1) What is WebAssembly (Wasm)? 2) How does it compare to Docker? and 3) How does this all relate to Atwood’s law? You should leave this Wagnerian saga with the equivalent of a couple tunes in your head.

WASM WTF

Perhaps the easiest way to think about WebAssembly is that it offers a way to take code written in programming languages other than JavaScript and run it within a web browser. The initial focus was on C/C++, but many languages are now getting onto the Wasm bandwagon. WebAssembly whispers in your ear the same alluring “write once, run anywhere” seduction that Java did (right before it poisoned your programmatic dreams with memory leaks). But there is some hope shining through the pessimism that WebAssembly may finally deliver on those promises because the kingdom of geeks is already way ahead of us: all major browsers offer basic support for WebAssembly! (Apologies to Internet Explorer.)

That “write once, run anywhere” prophecy can be fulfilled because WebAssembly is a compilation target. If you think of an internet browser as something of a virtual machine, then you can think of compiling code for that virtual machine in the same way you might compile code for machines with 32- or 64-bit architectures. Admittedly, that comparison isn’t 100% technically correct, but it’s easier to understand than the long-winded discussion of how compilers work. WebAssembly is an assembly language for a “conceptual machine” — a sort of simplified and abstracted way of thinking generally about all the machines that it might run on, and aren’t all problems in computing solved by some layer of abstraction?

Wasm does not require a separate container engine to run, so it does not have the additional performance overhead that a container or virtual machine layer might introduce. And that brings us to the next critical point: The execution of Wasm code can be very fast, running at near native speeds.

So what does that get us? First, this setup provides us with some diversity — JavaScript still gets used to interface with the WebAssembly modules and talk to a webpage via the DOM, but it no longer reigns supreme as the de facto ruler of the web. Secondly, by opening up the door to lower-level languages, your applications can make sensible tradeoffs, e.g. they can hand things over to WebAssembly when computationally heavy operations are required.

Admittedly, there aren’t many homesteaders out there on the WebAssembly frontier: Changes this fundamental will take a while to gain traction, but the future looks promising. Games have been ported (e.g. Doom3, and many others written in Unity) and some desktop applications too (e.g. Autocad). Even if you don’t want to write your own WebAssembly modules, you may want your web applications to leverage WebAssembly packages, available via the WebAssembly package manager (wapm). Ever wanted to do things like client-side image sizing or video editing? There are WebAssembly packages for those, but we’re getting ahead of ourselves…

WebAssembly and Docker

Maybe Wagner and George R. R. Martin were right… maybe you do need to keep introducing more characters to tell your story. The average discussion of WebAssembly doesn’t mention Docker, so we are really going into the deep plot of this tech opera, but now that you understand a bit of what WebAssembly is and does, I challenge you to unsee its similarity with Docker.

Like WebAssembly, Docker provides a sandboxed environment to run your application code. Like WebAssembly, you can package your applications written in any language into a container for simpler deployment. Like WebAssembly, Docker provides a kind of common currency so that various players can collaborate within a system. They are distinct technologies accomplishing different goals, but they are like armies allied against a common enemy.

Still not convinced? Consider the words of Solomon Hykes, the founder of Docker:

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! https://t.co/wnXQg4kwa4

— Solomon Hykes (@solomonstre) March 27, 2019

After all that explanation of what WebAssembly is and how it works in the browser, here we are throwing you a curveball: You can also run WebAssembly on the server. This may feel strange, but if Wasm is so awesome, why let the browsers have all the fun? Whereas Node.js solved this problem by bringing the JavaScript runtime environment to the server, Wasm built an environment and invited everyone to it.

The character that allows this plot twist is the WebAssembly System Interface (WASI). Because WebAssembly provides a fast and scalable way to run the same code across multiple machines, developers are pushing it beyond the browser, and that’s where the WASI comes in: Code outside of a browser needs a way to talk to the system. WebAssembly doesn’t need to talk to any single operating system, but rather, it needs an interface that lets it talk to a “conceptual operating system.” By introducing this layer of abstraction, WebAssembly can be run across all different OSs.

All of this probably doesn’t mean that Docker is doomed, but it might mean that Wasm containers start becoming increasingly common. Perhaps this layer of abstraction will allow Wasm to be the ubiquitous runtime for all applications regardless of language. Time will tell, but the foundations of this approach have been inviting promising solutions.

Atwood’s Law

It may seem odd at first glance, but I would like to close this article with some meditations on how WebAssembly relates to Atwood’s Law. The quote known as “Atwood’s Law” goes like this:

“Any application that can be written in JavaScript, will eventually be written in JavaScript.”
— Jeff Atwood, Author, Entrepreneur, Cofounder of StackOverflow

There are many misinterpretations of this quote, and however tempting it might be for snarky JavaScript developers to tout it as some evidence of divine authority, the actual source text was called “The Principle of Least Power” and it did not prophesize the subjugation of the internet by Angular, React, or Vue overlords. The actual message of that article was one that resonates deeply within all of us — within life itself, I would posit. In a nutshell, it says that there is real power in achieving more with less. This is as true with the evolution of life as it is with the internet and the formats that it uses to exchange data. If you can represent your data more simply, with less effort, then that representation will have an advantage over more complex and heady alternatives.

This is the subtle river that has been running through this saga from the beginning, and that’s where this story’s Rhinegold treasure truly lies: All of technology, WebAssembly included, attempts to disperse information, and its chances of survival are helped or hindered by how efficiently it succeeds at that task.

When viewed in this way, Atwood’s Law and its mention of JavaScript can be understood to mean a vote not necessarily for JavaScript explicitly, but an acknowledgement that simpler solutions will always prevail. JavaScript owes its ubiquity not to an arsenal of powerful things that it can do, but specifically to the calculated limitations that dictate what it cannot do. WebAssembly may be the next step forward in that evolution because it offers to do less than other alternatives. It even stores its instructions in plain old readable text instead of as unreadable binary, and this seems very much in keeping with the expansive goal of sharing data in the simplest means possible. It embodies the triumph of the bazaar over the cathedral, because exposing everything to the widest possible audience ensures that it can evolve, and this philosophy is to thank for much of Wasm’s success to date.

Nobody can guarantee the future, and it is absolutely possible that Wasm won’t fulfill all of our expectations. JavaScript founder Brendan Eich, who has been an advocate for WebAssembly, is concerned that conflicting competitive interests might end up splintering the Wasm project. Time will tell, of course, but WebAssembly is a technology that I definitely want to keep watching.