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.
Why is WebAssembly Important?
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.
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.
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.
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.
Thanks for reading ❤
If you liked this post, share it with all of your programming buddies!
Follow us on Facebook | Twitter
☞ The Web Developer Bootcamp
☞ Angular 7 (formerly Angular 2) - The Complete Guide
☞ Modern React with Redux [2019 Update]
☞ Vue JS 2 - The Complete Guide (incl. Vue Router & Vuex)
☞ Build Responsive Real World Websites with HTML5 and CSS3
☞ Why WebAssembly is a Big Deal?
☞ WebAssembly for Web Developers
☞ Front-end Developer Handbook 2019
☞ An Introduction to Web Workers
Originally published on https://medium.com