What is WebAssembly?

WebAssembly is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web

What it is, and why it matters for the future of web development

What is WebAssembly?

WebAssembly has steadily gained popularity since the founding of the WebAssembly Community Group back in 2015, but what exactly is it?

As defined by the authors at https://webassembly.org:

“WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.”

WebAssembly provides a lean stack-based virtual machine that allows web applications to run at near-native speed, by utilizing a fast-loading binary format which can also be converted into a text format for debugging.

This is a radically different approach to front-end software development on the web, in contrast to the typical use of heavy JavaScript libraries with layers of compatibility workarounds for issues which may not even exist in five or ten years. Four major browsers plus node have adopted it, which is a huge step towards finally achieving cross-browser compatibility, with high performance web applications being the default rather than the exception.

Why is WebAssembly Important?

If we look at the history of JavaScript, originally called Mocha, it was first conceived to be a full web application language and not just for front-end UI only. It took nearly 20 years for this to take full effect with the widespread adoption of Node, which was by then a novel concept to almost everyone.

The reasons for this are primarily driven by marketing, as Sun was touting JavaScript as a companion language to Java, something which often seems to resonate within certain large-scale enterprise cultures which use Java as their primary application language and see web front-end as just the place to get data in and out of an application. However, not everything is a simple CRUD enterprise app. If all you have is a hammer, everything looks like a nail. Well, sometimes you don’t need a hammer, you might need a saw or a CNC laser.

WebAssembly is only the second language to be natively understood by web browsers, with the first having been caught up in endless waves of standards compliance issues, serious performance problems, conflicting notions of how to go about implementing solutions, and giant cumbersome frameworks that often cause more problems than they solve in the long run. So, after a good 25 year run, it’s about time that at least one other language gets a shot at it.

Architectural Overview

WebAssembly is a virtual instruction set architecture (virtual ISA), which effectively allows a skilled developer to build modules that load quickly and run nearly as fast as compiled C or C++, as if these functions were compiled directly into the web browser itself. WebAssembly files come in two different formats, which can be converted to and from each other:

• .wat file: a human-readable S-Expression syntax file
• .wasm file: the machine-readable compiled binary file

Writing Web Assembly Text (.wat) files by hand is certainly an option, but it’s not the only one. Fortunately, there are many ways to generate and work with WebAssembly files. Here are just a few of them:

• A precompiled C++ to WebAssembly toolchain, available here
• A TypeScript-to-WebAssembly compiler, AssemblyScript
• The online WebAssembly notepad, WasmExplorer
• The online IDE, WebAssembly Studio
• Many other compiler options

More will be available as WebAssembly grows in popularity from widespread adoption by the authors of Chrome, Edge, Firefox, WebKit, and Node. It’s easy to see how this technology isn’t going away anytime soon and will likely have a very big impact on front-end development and web technologies as a whole.

Performance Benchmarking

As with any cool new technology that hits the scene, before we get all excited and go jumping on the bandwagon to potentially nowhere, it’s important to ask this time-honored question: why is this a good idea and should I bother?

There is no shortage of information and discussion about performance issues surrounding web applications, especially when it comes to single-page web apps and larger front-end interfaces with heavy bolt-on dependencies. There are entire areas of concern within the software industry that center around the notion of solving performance issues which in reality have been self-induced by the choice of using some framework X or technology Y to make web apps, since everyone else was doing it and that was the cool thing right?

Let’s take a look at some benchmarks from an excellent online tool which is the subject of an article on benchmarking WebAssembly using emulators:

WebAssembly in blue: lower is better in top graph, higher is better on bottom

The above two graphs are the result of a WasmBoy benchmark test, ran using the game “Back to Color” which is a demo game with a variety of audio and graphical events designed to showcase the features of the GameBoy Color. The benchmark was performed in Safari, on a 2017 13" MacBook Pro.

AssemblyScript compiled to WebAssembly is shown in blue, with the competitors being TypeScript compiled directly to ES6 (in yellow), and the Closure Compiler (in green). The test is useful in that the TypeScript logic for the emulator is essentially the same across the board, allowing us to test the performance difference between each of the compiler targets.

Note that these metrics are comparing apples-to-apples (to other efficienct tools) which means thatthe competitors are still high-performance ES6 implementations of a game emulator and not your typical website JavaScript. The difference in speed between a compiled WebAssembly application and a typical clunky framework app would likely be far greater.

In the top graph, the time-to-run per frame is displayed, which is the total amount of time required for drawing each frame (lower means faster). This time was far lower for WebAssembly than for either competitor.

The bottom graph displays the average frame throughput, or Frames Per Second. This metric shows where the different intro scenes of the first two thousand or so frames are taxing on each of the implementations of the emulator in different ways. On average, the WebAssembly version had a higher throughput than the others, especially for the intro animation.

#web-development #javascript #rust #c++ #webassembly