In case you haven’t heard, the Mozilla Firefox team recently released Firefox 52. The release includes the typical list of bug fixes and optimizations, but a big addition is the inclusion of WebAssembly support. The ambitions set by the WebAssembly community have the potential to change how people use devices and the web.
Sounds impressive, right?
Right now, most of the documentation around WebAssembly is meant for developers, which can make end users feel like they’re reading in the Peanuts adult voice.
What is WebAssembly anyway?
WebAssembly is meant to be a precompiled binary assembly format for applications that can run in browsers or outside them. Unlike Flash (which needs to die a long-overdue death), WebAssembly will be built into browsers, so no plugin will be necessary, kind of like how JavaScript is supported by default.
If I lost you at compiled, let me explain. Your typical desktop program, like Firefox, for instance, is a bunch of ones and zeroes compiled from source code. That source code can be written in a language like C or C++. But your PC (generally) doesn’t run C/C++ code directly; it must be compiled into those ones and zeroes.
WebAssembly is a binary assembly language (or an intermediate pile of ones and zeros) that is generic to all computers. When a PC downloads WebAssembly code, it says, “Oh hey, I understand this. It’s a program.” The PC can then assemble the code (an assembler is a kind of compiler) while making optimizations for the architecture and operating system.
This ain’t the JavaScript you’re used to
Most web applications today use JavaScript to run in the browser. JavaScript has been around for ages, and it’s gotten quite fast due to browser optimizations and hardware improvements. But at the end of the day, JavaScript is still an interpreted language, which means that the computer (or phone) has to parse and execute the code line-by-line. This can create some serious overhead, especially on mobile devices.
If you’ve ever wondered why a webpage might load and work just fine on a PC, but is slower on your phone while on the exact same Wi-Fi network, this latency is likely the culprit. That’s a big reason the app ecosystem exists: By running code that’s optimized for the device instead of the web, you get faster execution speeds and a snappier experience.
Think of compiled binary code as a device’s mother tongue. Interpreted code is like a foreign language. A CPU has to work harder to understand the interpreted code.
Put another way, think of the German word “Lastkraftwagen” in a news story as the source code. The translation to English, “truck,” is the WebAssembly assembly code. It’s a generic enough term to be understood by all English speakers. Now think of regional differences within the English language as each device’s specific architecture and optimizations: Before you read the story aloud to your friend from London, you might say “lorry” instead of “truck” since the story involves a commercial medium-duty vehicle, not a pickup truck. While some assembly might still be necessary on the device itself, WebAssembly saves your PC from having to go to Google Translate for every single word.
WebAssembly.org The Unity engine game Tanks! running in a web browser with WebAssembly.
Why this matters for users
If you’re thinking, “Big deal, I’ve been running compiled programs for ages,” you’re right. But you probably haven’t been running them in your web browser. WebAssembly promises a distribution format for applications that will be faster and “near-native” in speed.
Since WebAssembly is binary code running on your local machine, it means that visiting a Photoshop web application could feasibly be as responsive and quick as the desktop Photoshop application. The WebAssembly team even hope to see AAA game titles run in-browser. Both the Unity and Unreal Engine 4 engines are already working in WebAssembly. Epic has a short WebAssembly demo you can view if you’ve got Firefox 52 up and running. You can play a game of Tanks! with WebAssembly running in the Unity engine as well.
Epic’s Zen Garden is an interesting demo, but it shows how games and applications will likely run: The assets (textures, etc.) take much longer to download than the WebAssembly code itself. For games, this means you’ll still likely have to download and keep asset files locally, but the executable could be downloaded and run relatively quickly.
For Linux users, this is great news. One of the principal blocks to switching to Linux (or to Chrome OS for that matter) is that the user has some application that they rely on for work or play (I call them “mission-critical” apps). Getting a professional photographer who has a workflow set up in Adobe Lightroom to switch to Linux or Chome OS is pretty much a nonstarter since Adobe creative programs aren’t supported on Linux. With WebAssembly, Adobe could deploy creative programs like Lightroom by compiling to WebAssembly, instead of Windows or Mac OS.
WebAssembly also promises security for apps, as each WebAssembly application runs in its own sandbox. This means that WebAssembly can’t change anything on the system without access through an API or some other deliberate method. In other words, if a WebAssembly application is malicious, it shouldn’t be able to harm your system. (However, any information you offer to it can still be compromised.)
Taking into consideration package formats like Ubuntu’s snaps and Fedora’s Flatpak, WebAssembly has the potential to dominate both. That is, if developers adopt the format and start deploying it.