If you’ve been keeping up with the JavaScripts, chances are you’ve heard snatches of excitement about the latest and greatest in web technology, WebAssembly. WebAssembly is a binary executable for the web that promises near-native performance for web applications. This means that graphics heavy applications like Photoshop, and AutoCAD can now be run in the browser without the need for clunky third party plugins like Silverlight, Flash and Java Applets. Web Assembly effectively removes the notion that JavaScript is the de-facto assembly language of the Web and opens the door for other languages like C, and C++ to run on the web.
The conception of WASM
To better understand why WebAssembly is such a big deal, let’s briefly examine the history of the web with a focus on JavaScript’s impact on it. In the early days, the web was static (read: purely text-based) and HTML was the dominant language for building websites. Mocha, which later became modern day JavaScript, was created to enable interactivity and dynamism on the web, so animations and user input events were now possible. At this time however, JavaScript was incredibly slow and it wasn’t only until 2008 (almost 13 years after the invention of JS) that significant performance improvements were made to browsers via Just in Time (JIT) Compilers. These compilers boosted the performance of JavaScript by an order of magnitude and pushed the boundaries of what was possible to run in the browser. This boost in performance thanks to JIT compilers however was short-lived as developers started putting JavaScript on the server (hello Node.js!) and further stretched the limitations of the JavaScript engine. In addition, device manufacturers were creating evermore complex high fidelity devices like VR headsets that demanded faster rendering speeds and challenged browser capabilities. If the web continued on their current trajectory, they would risk losing out to the much faster and reliable native web. Web Assembly was introduced from this furor as a means of making sure applications could run in the browser while still taking advantage of native optimizations.
What about ASM?
WASM was of course not the first time that browser vendors had thought about “natively” porting native applications to the web. In fact, asm.js and Native Client (NaCl)/Portable Native Client (PNaCl) were the first attempts made by Mozilla and Google respectively to use JavaScript as a target language for cross-compilation. More specifically, asm.js gave the developers the tools via Emscripten to compile large C/C++ applications into JavaScript and leveraged the capabilities of WebGL so they could run seamlessly in the browser. On the other hand. NaCL was a sandbox environment to run C/C++ code in the browser that was independent of a user’s operating system and Portable NaCl, like asm.js allowed developers to compile their code down with ahead-of-time (AOT) translation. Because asm.js was just a subset of JS, while NaCl/PNaCL only worked on Chrome/Chromium, asm.js eventually “won out”. Even so, for a host of many reasons, including the lack of a formal specification, and any speed guarantee whatsoever, asm.js was eventually replaced for WASM though the former served as a blueprint for the latter. For more on why asm.js was replaced by WASM, check out Brendan Eich’s in depth post.
What’s the big idea?
A common misconception with WebAssembly is that its introduction rings the death knell of JavaScript. While WebAssembly opens the door for other languages to run on the browser, WebAssembly will not (and will probably never) usurp JavaScript from its reigning throne as the de-facto language of the web. (Sorry haters) Instead, WebAssembly will be executed in the same universe as JavaScript and rely on it to communicate with the browser. Moreover, JavaScript can lean on the speed and optimizations that WASM provides to run “heavier” applications without worrying about any performance drawbacks.
It’s not all fun and games
A compelling use case for WASM has largely been for optimizing games in the browser. This makes sense because games rely on performance critical functionality like high fidelity renders and fast refresh rates. WASM therefore let game developers execute at native speed and take advantage of common hardware capabilities all while operating within the constraints of a browser. Considering the speed optimizations and native functionality that WASM gives developers access to, there are many more applications that WASM can be used for. One of these applications that I personally am most excited about is the applicability of WASM for progressive enhancement and PWAs.
At a basic level, progressive enhancement is the deliberate strategy of building apps on the foundation of making it usable everywhere. This means that applications are built with a base level of user experience with added, advanced functionality for browsers that support it. PWAs build on the idea of progressive enhancement and provide a well-defined structure of how to build for progressive enhancement—things like service workers, HTTPs and so on. While PWAs recommend making web applications native-like, WASM makes it possible for native applications to run seamlessly in the browser, thereby boosting the possibilities of what a PWA can look like. For instance, with WASM, you could sandbox business logic that would otherwise be squirreled away in a separate service call to an external API into a WASM module that you can run natively from the application itself. Users now have access to incredibly powerful and efficient tools from within their browser and don’t have to download yet another application to get full native functionality. Not only that, by delivering highly performant (and safe!) applications, WASM champions the web and advocates for it as the default platform for running applications.
Heart open, Eyes bright
It is undeniable at this point that WebAssembly is (and will be) a huge game changer for web development. As a lower level language, it efficiently handles more computationally heavy tasks and allows us to so more, with less. Though we’re still in the early stages of WASM, the future looks bright. I can’t make many strong predictions for the future that Web Assembly brings (though Lin Clark over at Mozilla may know!), but I can say that when you bet on the web, you always win.