traffic on highway at night
PHOTO: Robin Pierre

Imagine you wanted to write an application for a design studio that was capable of creating amazingly realistic 3-D previews of the interiors of restaurants. Using the app, a customer of the design studio just points a phone camera at the corner of a room made of rough concrete and a reddish-brown mahogany bar with the latest Saint-Émilion wine selection appears on the display, as if by magic. He takes a step to one side, zooms out and a row of tables materializes. If you had to create such an app, what would your technology choices be?

Performing augmented reality on the client side at low latency and 60fps is not the only job where JavaScript as an interpreted language has performance shortcomings. Think of interactive games, CAD, encryption or video encoding. Traditionally, there have been two approaches to compensating for less than optimal execution speed: perform the tasks at the server side (while compromising on latency and possibly blowing your mobile data bill) or use technologies like Adobe Flash or Silverlight that aim to bridge the web and native worlds via browser plugins. With HTML5 and JavaScript APIs like WebGL eating away at the justification for the existence of plugins, this approach has gradually been abandoned.

Meet WebAssembly

However, one notable approach for filling performance holes on the client side has been in development for some time and just recently achieved support in all four major browsers: WebAssembly.

Briefly, WebAssembly is a new, portable binary format suitable as a compilation target for common programming languages. You can think of it as an assembly language for the web. It is being designed as an open standard by a W3C community group that includes representatives from Mozilla, Microsoft, Google and Apple. The initial minimally viable product (MVP) API and binary format have been completed. So far, tooling for compiling C/C++ and Rust to WebAssembly exists, but planned next steps in the development involve adding support for garbage collection, which would make it possible to add Java and C# to the list. A textual representation of the binary format already exists, and it could come in handy when debugging.

Besides near-native execution performance and size- and load-time efficiency of client code, there are other possible benefits surrounding WebAssembly, including the following:

  • Usage of the same model on the client and the server. When you introduce JavaScript code into a .Net or Java project, you embark on a code duplication journey, adding to the cost of code writing and maintenance. Think of a model class defined in the backend REST service code and its JavaScript copy for a client-side model-view-viewmodel (MVVM) framework such as Knockout.js on the front end. Wouldn’t life be easier if one could reuse the class written in a managed programming language by compiling it into WebAssembly?
  • Porting of external code bases to the web platform. There could be no more need for service façades around 20-year-old code that is too geeky (and brittle) to be rewritten to JavaScript.

What Makes WebAssembly Different?

This is not the first attempt to bring native code to the web space. Since previous attempts like Java Applets, Flash or Silverlight failed to reach wide adoption, it is worth asking why WebAssembly should fare any better. Let’s compare some deficiencies of those earlier offerings and see whether they apply in our case:

  • Initiative of a single company: WebAssembly is the exact opposite of a proprietary technology. It is an open standard with the most important players as stakeholders. This broad coalition should give WebAssembly the credentials it needs to gain acceptance by the open source community.
  • The need to install a browser plugin (or worse, platform dependence, as with ActiveX): As of this time, WebAssembly is natively supported by Firefox, Chrome, Safari and Edge, which, according to NetMarketShare.Com, collectively account for 79 percent of the desktop browser market and 87 percent of the mobile browser market. Cross-platform support out of the box removes an important hurdle to user adoption: the need to wait for a download to complete and then install a plugin despite all the browser’s security warnings.
  • HTML5 rendered much of the functionality of previous offerings obsolete: The value proposition of WebAssembly is not to compete with HTML or JavaScript, but rather to fill their gaps. The goal is a happy coexistence instead of a collision. This philosophy may require changes to WebAssembly as HTML5’s capabilities expand, but it is safe to assume there will always be gaps for WebAssembly to fill.

Related Article: W3C Partners With Google, Facebook, Microsoft and Others to Create Web Standards Documentation Site

A Technology to Be Taken Seriously

WebAssembly is a technology designed to be taken seriously, not only because it has the support of global players, but also because of its interoperability with the existing web ecosystem. Its promise of adding new features to the web platform without introducing incompatibilities or vendor lock-in is likely to be welcomed both by the developer community and business executives.

The WebAssembly W3C community group’s declaration that post-MVP features will be designed in a backward-compatible manner invites early adopters to begin experimenting. In the near future, once WebAssembly introduces support for at least one major managed language compiler (e.g., Java or C#), we will see broader adoption.

Over time, WebAssembly is likely to become a standard tool for web apps needing CPU-intensive calculations or reduced load times, and it will perhaps provide some interesting extras to bridge the gap between the front and back ends.