Much has been said lately about web assembly. How it will kill javascript, how it will not, and lots of other controversial opinions.
But even thought hearing about web assembly is recurrent, very few people really know what is web assembly and what are its benefits, when they should use it, and even if they should use it at all.

So, in order to make it a less confusing topic, I will be writing a series of articles covering from the very basics of web assembly, to making a simple web assembly application

In this first article I will cover, what is web assembly, why it's faster than regular javascript (in a very superficial way. But I will drop some links for those who want to deeply understand the matter), and finally show some examples of applications running it.

What is Web Assembly

"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."

This description is taken directly from the web assembly's website main page (https://webassembly.org/)

So, by looking at this description, we can figure out that web assembly is not a programming language. But if it is not a programming language, then what is it ?

web assembly is a compiler target

What is a compiler target ?

In order to understand a compiler target, first we have to understand what exactly is a compiler. Roughly speaking, a compiler is a translator, which (generally) translates the code we give to it, to a lower level code. That is what web assembly is, the result of the compilation from one "high level" (even thought c/c++/Rust aren't as high level as javascript or python, they are still high level languages when compared to machine code).

So, will web assembly kill javascript or not ?

Absolutely not. it's not even its intention. Wasm's main goal is to be an javascript ally, handling heavier and more complex calculations. One of the main proofs that web assembly's goal isn't to replace javascript, is that it doesn't even have access to the DOM API, meaning that it isn't able to change what we see in our html files.

Why it is faster than javascript

The secret of its speed relies on two key factors.

1- Javascript complexity

Javascript is a language designed to be easily understood by humans. What is a double edged blade, because while it is indeed easy to read and write code in javascript (or at least easier than in most languages), this ease comes with a price. In order for javascript to be so "hackable" and having multiple ways of doing the same thing, it has to make a bunch of validations even to do the simplest things. For example

What do you think javascript has to do in order to return you the result of the following ?

const add = (a,b) => {
  return a + b;
}

It should do something pretty simple, right ? Wrong

It has to do a bunch of validations in order to know what it should do with the parameters a and b.

Are a and b strings ? if so, it will concatenate them

const result = add('hello ', 'my friend');

//result will be equal to 'hello my friend';

is b a number, and a an string ? if so, it will turn the number into a string and then concatenate a and b

const result = add(1, ' is a nice number');

//result will be equal to '1 is a nice number';

or even, are a and b numbers ? in that case the numbers will be added, returning a numeric value

const result = add(1, 1);

//result will be equal to '2';

and the validation list looks something like the image bellow, taken from Alex Danilo talk about web assembly in Google I/O 17

Compiling for the Web with WebAssembly (Google I/O '17)

that isn't the case with lower level languages (such as the ones supported by web assembly) since they don't do these verifications and operators tend to have one lexical meaning, instead of many, such as in javascript, where the same operator/instruction oftenly has more than one meaning.

If we went through all this complication just to add two parameters, imagine what kind of validations more complex operations require. Having this whole bunch of code being run makes your application slower

2- Wasm code has to go through fewer steps than javascript in order to be run by the browser

Even thought javascript is a interpreted language and doesn't have to be compiled in order for it to run, modern browsers use JIT's (just in time compilers) to optimize it, making its performance significantly better than it would be otherwise.

This optimization runs in multiple steps, which vary from browser to browser. But if you are seeking a deep understanding of the optimization process, some of its flaws and why web assembly solves problems unsolved by this optimization process, you should check Lin Clark's awesome talk about the subject

Lin Clark: A Cartoon Intro to WebAssembly | JSConf EU 2017

if you don't want to dive that deep into the details, just trust me (and the following image) when i tell you that Wasm code goes trough fewer steps separating the download of the file from its execution,hence it's faster.

Use cases

01 - Video editor demo in Wasm

This first example is just a demo, of a simple web editor running in web assembly displayed in the same page of the same editor, but running completely in javascript. The performance of both implementations is shown and compared in the page

02 - Figma

Figma is one of the most widely known web assembly cases, because it is one of the first applications to use it in production, and probably the one of the most relevant ones. And they even wrote an article about their use of web assembly

03 - Google Earth

Google earth also uses web assembly in order to make the rendering of its complex 3d shapes possible in the web. Similarly to figma, they also have a post explaining its use of web assembly

Now we finally know what Wasm is, why it is fast and some tools that are already using it 🎉🎉🎉🎉🎉

This was only the first part of a series about web assembly. If you liked it, please:

• Follow me on Twitter: @gabriel__eloy

• Stay tuned for the next parts of this series