WebAssembly, in truth, neither is strictly web nor assembly. Then what is it? We will try to answer this question in this short blog series about WebAssembly.
This post is meant to be the first in a series aimed at exploring WebAssembly and how it actually works. In this post we are going to start with a high-level overview of WebAssembly, how it works, what it brings to the web and how it will affect JavaScript.
In looking for an answer, a good place to start is providing a definition from the WebAssembly homepage: "WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. WebAssembly 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".
This definition may seem complicated for someone who was not in touch with stack-based virtual machine or binary instruction formats before, so let’s try to explain it. To put it simply, WebAssembly is a way of running programming languages, other than JavaScript, in the web browser. WebAssembly opens the passage for many programming languages to web. For example, WebAssembly made it possible to take existing C/C++ desktop applications and run it inside the browser. Sounds pretty good, right?
But it’s important to emphasize that you can’t just run your code through a compiler and have it produced WebAssembly in a way so that it magically works. There should be some modifications done on the code.
Although it can be written and viewed in a human-readable format (wat file), WebAssembly is not meant to be a programming language that humans write directly, rather a set of binary instructions that is generated by a compiler from some higher-level programming language. Binary representation is what is actually delivered to the browser.
As we said in the WebAssembly definition, it’s a binary instruction format executed in a stack-based virtual machine. If you are a Java developer, this concept may sound familiar to you because Java works in the same way. Java files are compiled into bytecode (.class files) which is executed by Java Virtual Machine (JVM).
JVM is a stack-based virtual machine.
WebAssembly follows exactly the same concept except it runs inside the browser.
The WebAssembly development cycle is similar to most other languages that require compilation. It is delivered in following development workflow: the first step is generating a .wasm file, usually by compiling from a higher-level programming language, but we can also write a program in WebAssembly text format and compile it into a WebAssembly binary file. In the second step we load and execute the generated WebAssembly module. The module is loaded through the JavaScript ‘glue code’ and executed inside the WebAssembly virtual machine.
There are many different methods for loading the Wasm module which you can check out on WebAssembly API page.
It is very important to understand that WebAssembly is sandboxed inside the browser, just like JavaScript, which means that it can’t access your computer’s resources, like the file system. It also means that the memory between the WebAssembly application and the JavaScript code is shared.
On the image above, you can see there is two-way communication between JavaScript and WebAssembly. JavaScript is used to load WebAssembly file, so you can call the WebAssembly functions inside the browser, but you can also pass JavaScript functions to WebAssembly. Actually, the only way to access the Web APIs from WebAssembly is to call the JavaScript function. Of course, that comes with a performance cost, so you should use it with care. JavaScript is still a good choice for using web APIs, for example for manipulating DOM.
One of the main reasons that makes WebAssembly so attractive is its efficiency and speed. Because WebAssembly is an already compiled compact binary format, it is faster to download it over the network in comparison to JavaScript files, which are textual files that need to be parsed and optimized. The WebAssembly file has already gone through that phase during its compilation phase, so Wasm is faster because it only needs to be decoded, while JavaScript needs to be parsed. Another amazing thing is that WebAssembly can be compiled to machine code while it’s being downloaded. This is called Streaming Compilation. Since download and compilation happen in parallel, this is faster, especially for large payloads.Â
Another very important thing to mention is that WebAssembly was designed with portability in mind and follows the write once, run anywhere principle. Because of that, it is supported in all major browsers, as well as in the server-side JavaScript runtime Node.js and desktop environments.
Since WebAssembly came onto the scene, like with every new technology, there have been speculations about whether it will kill the old technology – JavaScript? The short answer is: no (at least not anytime soon). WebAssembly is not created to be a JavaScript replacement, but rather its complement. Just like video (TV) hasn’t killed the radio, but it has improved it in a new and exciting way that we never could have dreamed possible, WebAssembly will not kill JavaScript. Video brought a new dimension to radio. Video can show action rather than just describe it. For example, you can listen to a broadcast of a football match on the radio while you’re driving, but it is better to watch it live on TV. Still, if you want to discover and listen to new music, radio is still the better choice. Radio still exists, and it will exist in the future for one main reason: Radio is mobile. You can listen to the radio on your way to work, during cooking or a long road trip. On the other hand, video offers more creativity and a visual element that is not available with radio. Let’s take ads for example. TV ads allow businesses to show their products, tell stories about those products, and generate laughter and emotion, without having to tell the audience how to feel. Both TV and radio have advantages and disadvantages in certain aspects. It is the same with WebAssembly and JavaScript.
We can compare this relationship between video and radio with WebAssembly and JavaScript, where WebAssembly is video and JavaScript is radio. Just like video opened a set of new possibilities, WebAssembly is opening up all kinds of possibilities for web development. WebAssembly programs can go where no JavaScript has gone before. Because WebAssembly is designed for hard computational tasks, it is a great replacement in all those use cases where JavaScript would usually struggle to reach the needed performance level. For example, image recognition, 3D rendering, VR and high-end games, transcoding, emulation, desktop-tier applications, etc. But JavaScript still has its own advantages, like simplicity and popularity and it is here to stay and to work together with WebAssembly on a more powerful web.
In this blog post we gave a short overview of WebAssembly, how it works and what it brings to the web. We saw WebAssembly development workflow and its great efficiency and speed. With WebAssembly we can take existing libraries, games, and command-line tools written in other programming languages and run them on the web at almost native speed.
WebAssembly is still in active development, but it already changing how we develop web and sure it will be a part of the web future. WebAssembly will stop JavaScript domination on the web and fill the gap where JavaScript falls short, for example in speeding up high computational tasks. WebAssembly is a great addition to our toolbox in developing web. We can see the light at the end of the tunnel for web development.
For more details on WebAssembly, I highly recommend checking out the Awesome Wasm git repository where you can find tones of interesting things about WebAssembly.
WebAssembly in action
On the links below you can see some real-world examples of WebAssembly in action: