Intive Blog

WebAssembly: an alternative to JS

We, Frontend developers, are used to working with plenty of tools. However, the raw material we build everything on simply comes down to 3 technologies, which make up the web:

  • HTML
  • CSS
  • JS

WebAssembly comes as an answer to what we asked in the Frontend team as regards JS (javascript), which is currently THE web programming language. Thousands of libraries, frameworks, tools, etc, are built on this language. So the questions came up: What if we wanted to program for the web without JS? Is there a way? What would that be like?


ams.js was developed some years ago, it tried to bring the lowest-level programming and the web closer, but still through JS. Back in the time, many ams developers understood that JS should not be a middle agent but a peer as they started developing WebAssembly (a.k.a wasm). The objectives for this new language were to be:

  • Fast, efficient and portable. Wasm can be run with a speed close to native code.
  • Legible and “debuggable”. Although wasm is a low-level language, it has a text format which can be read by humans (the specification is not yet finished).
  • Secure: Wasm runs on a secure environment.


But, how does wasm work on the web? We can think that the latter is made by:

  • A virtual machine that runs the web code, generally JS.
  • A group of Web APIs that can control the device and the browser. For instance: DOM, WebGL, Service Workers, Local Storage, etc.

At the same time we can imagine a browser as a Full Stack developer that performs lots of different kinds of tasks. Such as rendering, compiling, rooting, optimizing, decompressing (unzipping?), etc. Wasm is used by the browser in all these aspects, but in a more efficient way.


Let’s see now how JS and wasm are interrelated.

  • JavaScript is a high-level language, very flexible, with many advantages and which also features a vast ecosystem of frameworks and libraries.
  • Wasm is a low-level language, with a compact binary format, which can be run with performances close to the native ones, and gives a target where to be compiled by low-level languages, such as C++ and Rust to be run on the web.
  • The WebAssembly JavaScript API wraps wasm code with JS features that can be called normally, and the wasm code can import functions and call JS features synchronously.


Wasm comes with a full terminology associated, which will help us understand later some examples and how to use it. The following are some concepts which are worth clearing out beforehand:

  • Module: It is a binary code that was compiled on the browser, and converted into code that can be used by the computer. Modules do not have status, therefore they can be shared between windows, tabs, service workers, or cached.
  • Memory: An ArrayBuffervariable in sizw, which has the bytes which are read and written by the wasm module, through instructions of the low-level memory.
  • Table: An array of references, of variable size, that because of portability and security cannot be stored in Memory.
  • Instance: It is the execution of a module, along with its status, including their Memory, Tables and the values it imported.


How is wasm used? There is not still a way for the browser to bring the wasm modules. The current way of doing so is by means of the following procedure:

1) Asking for the file through fetch or XMLHttpRequest

2) Create an ArrayBuffer that contains the binary code

3) Compile it using WebAssembly.instantiate().

In this way, the code would be as follows:


The process that implies the execution of the code on JS and wasm, differs in the quantity of stages, times and type of processes. Let’s see some differences:

1) Parse

Screen Shot 2017-12-14 at 11.29.35 AM

Decodifying WebAssembly takes less time than JavaScript

Screen Shot 2017-12-14 at 11.29.46 AM

2) Compiling

Screen Shot 2017-12-14 at 11.29.53 AM

Compiling and optimizing takes less time because WebAssembly is closer to the code the machine runs which is JavaScript, and furthermore it is already optimized when it is sent to the browser.

3) Reoptimize

Screen Shot 2017-12-14 at 11.29.59 AM

WebAssembly does not need optimizations, since it is a typed language and has other own definitions that JS does not have and forces the JS engine during running/compilation time.

4) Execution

Screen Shot 2017-12-14 at 11.30.06 AM

It usually takes less time since the languages that compile to wasm, generally push the developer into making performance decisions and does not leave much room for errors since they become evident out. Also, the set of wasm instructions is more adequate for machines than JS.

5) Garbage Collection

Screen Shot 2017-12-14 at 11.30.20 AM

It is not necessary, since the languages that compile to wasm do not usually use it and this forces the developer to manage memory in a conscious, consistent and careful way.


To perform tests or show examples there is a very useful fiddle:

The code can be also run importing the wasm module on any fiddle.,console

Here is the code:


Wasm is not currently actually defined. Its standard and technical specifications are not only incomplete but they are also still going through a process of correction and development.

In the test we present (calculating the square root and converting a text to capital letters) you cannot see much difference as regards runtime. Although this can be due to the fact that the JS code in this case is super optimized and does not have re optimizations.

In other examples we came across with a more complex logic (actually complex) we could not see any difference either. But where you can actually see cases of success is on the images processing application. However, this demands great work of development on codes such as C, Rust or others.

“When we say ‘actually complex’, we refer to cases such as the ones in the course on sobre WebAssembly:



In conclusion, Wasm does not work for a frontend developer to code what s/he needs leaving JS aside for a couple of hours. It is not a new JS framework but in works in parallel, replacing it. To take full profit of it you need to put in time and exclusive efforts, it is necessary to make up your mind between JS and wasm.


Pablo Hiyano

Pablo Hiyano is coordinator of technical teams at intive-FDV. A student of Biology at Universidad de Buenos Aires (UBA), since kid his great interest in programming made him a self-taught developer passionate for the Javascript world. In his free time, he enjoys playing with his child, watching british series and reading about philosophy, especially works by Michel Foucault.

Add comment