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.
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.
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…
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
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.
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:
— Jeff Atwood, Author, Entrepreneur, Cofounder of StackOverflow
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.
Everett Griffiths is a developer with close to 20 years’ experience developing web applications and APIs with an emphasis on performance and testability. He has authored two books on development and taught bootcamps at the University of Southern California focusing on coding fundamentals and the principles of data science.
Subscribe to be the first to get our expert-written articles and tutorials for developers!