WebAssembly is not a high-level programming language like JavaScript, but a compiled binary format that all major browsers are currently able to execute. WebAssembly is a kind of machine bytecode that was not designed to run directly on any real machine hardware, but runs in the JavaScript engine built into every browser. In some ways, it is similar to the old Java Virtual Machine (JVM); for example, it is a platform-independent compiled bytecode. One major problem with JavaScript bytecode is its requirement for a plugin to be downloaded and installed in the browser for the bytecode to run. Not only is WebAssembly designed to be run directly in a browser without a plugin, but it is also intended to produce a compact binary format that executes efficiently inside a web browser. The MVP version of the specification leverages existing work by the browser makers designing their JavaScript just-in-time (JIT) compiler. WebAssembly is currently a young technology and many improvements are planned. However, developers using the current version of WebAssembly have already seen performance improvements over JavaScript of 10–800%.

JavaScript has been around for a long time. It has evolved from a little scripting language that allowed bells and whistles to be added to a web page, to a sprawling JIT compiled language with a massive ecosystem that can be used to write fully fledged applications. Today, JavaScript is doing a lot of things that were probably never imagined when it was created by Netscape in 1995. JavaScript is an interpreted language, meaning that it must be parsed, compiled, and optimized on the fly. JavaScript is also a dynamically typed language, which creates headaches for an optimizer.

WebAssembly solves a lot of the problems created by JavaScript and its long history in the browser. Because the JavaScript engine is already in bytecode format, it does not need to run a parser, which removes a significant bottleneck in the execution of our application. This design also allows the JavaScript engine to know what data types it is dealing with at all times. The bytecode makes optimization a lot easier. The format allows multiple threads in the browsers to work on compiling and optimizing different parts of the code at the same time.

WebAssembly is not a high-level programming language, but a binary file with opcodes for a virtual machine. Currently, it is considered to be in an MVP stage of development. The technology is still in its infancy, but even now it offers notable performance and file size benefits for many use cases, such as game development. Because of the current limitations of WebAssembly, we have only two choices for languages to use for its development—C/C++ or Rust. The long-term plan for WebAssembly is to support a wide selection of programming languages for its development. If I wanted to write at the lowest level of abstraction, I could write everything in Web Assembly Text (WAT), but WAT was developed as a language to support debugging and testing and was not intended to be used by developers for writing applications.

As I have mentioned, WebAssembly is 10–800% faster than JavaScript, depending on the application. To understand why, I need to talk a little about what a JavaScript engine does when it runs JavaScript code versus what it has to do when it runs WebAssembly. I am going to talk specifically about V8 (the Chrome JavaScript engine), although, to my knowledge, the same general process exists within SpiderMonkey (Firefox) and the Chakra (IE & Edge) JavaScript engines.

The first thing the JavaScript engine does is parse your source code into an Abstract Syntax Tree (AST). The source is broken into branches and leaves based on the logic within your application. At this point, an interpreter starts processing the language that you are currently executing. For many years, JavaScript was just an interpreted language, so, if you ran the same code in your JavaScript 100 times, the JavaScript engine had to take that code and convert it to machine code 100 times. As you can imagine, this is wildly inefficient.

The Chrome browser introduced the first JavaScript JIT compiler in 2008. A JIT compiler contrasts with an Ahead-of-Time (AOT) compiler in that it compiles your code as it is running that code. A profiler sits and watches the JavaScript execution looking for code that repeatedly executes. Whenever it sees code executed a few times, it marks that code as "warm" for JIT compilation. The compiler then compiles a bytecode representation of that JavaScript "stub" code. This bytecode is typically an Intermediate Representation (IR), one step removed from the machine-specific assembly language. Decoding the stub will be significantly faster than running the same lines of code through our interpreter the next time.

Here are the steps needed to run JavaScript code:

While all of this is going on, there is an optimizing compiler that is watching the profiler for "hot" code branches. The optimizing compiler then takes these code branches and optimizes the bytecode that was created by the JIT into highly optimized machine code. At this point, the JavaScript engine has created some super fast running code, but there is a catch (or maybe a few).

The JavaScript engine must make some assumptions about the data types to have an optimized machine code. The problem is, JavaScript is a dynamically typed language. Dynamic typing makes it easier for a programmer to learn how to program JavaScript, but it is a terrible choice for code optimizers. The example I often see is what happens when JavaScript sees the expression c = a + b (although we could use this example for almost any expression).

Just about any machine code that performs this operation does it in three steps:

1. Load the a value into a register.

2. Add the b value into a register.

3. Then store the register into c.

The following pseudo code was taken from section 12.8.3 of the ECMAScript® 2018 Language Specification and describes the code that must run whenever the addition operator (+) is used within JavaScript:

1. Let lref be the result of evaluating AdditiveExpression.
2. Let lval be ? GetValue(lref).
3. Let rref be the result of evaluating MultiplicativeExpression.
4. Let rval be ? GetValue(rref).
5. Let lprim be ? ToPrimitive(lval).
6. Let rprim be ? ToPrimitive(rval).
7. If Type(lprim) is String or Type(rprim) is String, then
   a. Let lstr be ? ToString(lprim).
   b. Let rstr be ? ToString(rprim).
   c. Return the string-concatenation of lstr and rstr.
8. Let lnum be ? ToNumber(lprim).
9. Let rnum be ? ToNumber(rprim).
10.Return the result of applying the addition operation to lnum and      
   rnum.

This pseudo code is not the entirety of what we must evaluate. Several of these steps are calling high-level functions, not running machine code commands. GetValue for example, has 11 steps of its own that are, in turn, calling other steps. All of this could end up resulting in hundreds of machine opcodes. The vast majority of what is happening here is type checking. In JavaScript, when you execute a + b, each one of those variables could be any one of the following types:

• Integer
• Float
• String
• Object
• Any combination of these

To make matters worse, objects in JavaScript are also highly dynamic. For example, maybe you have defined a function called Point and created two objects with that function using the new operator:

function Point( x, y ) {
    this.x = x;
    this.y = y;
}

var p1 = new Point(1, 100);
var p2 = new Point( 10, 20 );

Now we have two points that share the same class. Say we added this line:

p2.z = 50;

This would mean that these two points would then no longer share the same class. Effectively, p2 has become a brand new class, and this has consequences for where that object exists in memory and available optimizations. JavaScript was designed to be a highly flexible language, but this fact creates a lot of corner cases, and corner cases make optimization difficult.

Another problem with optimization created by the dynamic nature of JavaScript is that no optimization is definitive. All optimizations around typing have to use resources continually checking to see whether their typing assumptions are still valid. Also, the optimizer has to keep the non-optimized code just in case those assumptions turn out to be false. The optimizer may determine that assumptions made initially turn out not to have been correct assumptions. That results in a "bailout" where the optimizer will throw away its optimized code and deoptimize, causing performance inconsistencies.

Finally, JavaScript is a language with Garbage Collection (GC), which allows the authors of the JavaScript code to take on less of the burden of memory management while writing their code. Although this is a convenience for the developer, it just pushes the work of memory management on to the machine at run time. GC has become much more efficient in JavaScript over the years, but it is still work that the JavaScript engine must do when running JavaScript that it does not need to do when running WebAssembly.

Executing a WebAssembly module removes many of the steps required to run JavaScript code. WebAssembly eliminates parsing because the AOT compiler completes that function. An interpreter is unnecessary. Our JIT compiler is doing a near one-to-one translation from bytecode to machine code, which is extremely fast. JavaScript requires the majority of its optimizations because of dynamic typing that does not exist in WebAssembly. Hardware agnostic optimizations can be done in the AOT compiler before the WebAssembly compiles. The JIT optimizer need only perform hardware-specific optimizations that the WebAssembly AOT compiler cannot.

Here are the steps performed by the JavaScript engine to run a WebAssembly binary:

The last thing that I would like to mention is not a feature of the current MVP, but a potential future enabled by WebAssembly. All the code that makes modern JavaScript fast takes up memory. Keeping old copies of the nonoptimized code for bailout takes up memory. Parsers, interpreters, and garbage collectors all take up memory. On my desktop, Chrome frequently takes up about 1 GB of memory. By running a few tests on my website using https://www.classicsolitaire.com, I can see that with the JavaScript engine turned on, the Chrome browser takes up about 654 MB of memory.

Here is a Task Manager screenshot:

With JavaScript turned off, the Chrome browser takes up about 295MB.

Here is a Task Manager screenshot:

Because this is one of my websites, I know there are only a few hundred kilobytes of JavaScript code on that website. It's a little shocking to me that running that tiny amount of JavaScript code can increase my browser footprint by about 350 MB. Currently, WebAssembly runs on top of the existing JavaScript engines and still requires quite a bit of JavaScript glue code to make everything work, but in the long run, WebAssembly will not only allow us to speed up execution on the web but will also let us do it with a much smaller memory footprint.

The short answer to this question is not anytime soon. At present, WebAssembly is still in its MVP stage. At this stage, the number of use cases is limited to applications where WebAssembly has limited back and forth with the JavaScript and the Document Object Model (DOM). WebAssembly is not currently able to directly interact with the DOM, and Emscripten uses JavaScript "glue code" to make that interaction work. That interaction will probably change soon, possibly by the time you are reading this, but in the next few years, WebAssembly will need additional features to increase the number of possible use cases.

WebAssembly is not a "feature complete" platform. Currently, it cannot be used with any languages that require GC. That will change and, eventually, almost all strongly typed languages will target WebAssembly. In addition, WebAssembly will soon become tightly integrated with JavaScript, allowing frameworks such as React, Vue, and Angular to begin replacing significant amounts of their JavaScript code with WebAssembly without impacting the application programming interface (API). The React team is currently working on this to improve the performance of React.

In the long run, it is possible that JavaScript may compile into WebAssembly. For technical reasons, this is a very long way off. Not only does JavaScript require a GC (not currently supported), but because of its dynamic nature, JavaScript also requires a runtime profiler to optimize. Therefore, JavaScript would produce very poorly optimized code, or significant modifications would be needed to support strict typing. It is more likely that a language, such as TypeScript, will add features that allow it to compile into WebAssembly.

JavaScript is currently ubiquitous on the web; there are a tremendous number of libraries and frameworks developed in JavaScript. Even if there were an army of developers eager to rewrite the entire web in C++ or Rust, WebAssembly is not yet ready to replace these JavaScript libraries and frameworks. The browser makers have put immense efforts into making JavaScript run (relatively) fast, so JavaScript will probably remain as the standard scripting language for the web. The web will always need a scripting language, and countless developers have already put in the work to make JavaScript that scripting language, so it seems unlikely that JavaScript will ever go away.

There is, however, a need for a compiled format for the web that WebAssembly is likely to fulfill. Compiled code may be a niche on the web at the moment, but it is a standard just about everywhere else. As WebAssembly approaches feature-complete status, it will offer more choices and better performance than JavaScript, and businesses, frameworks, and libraries will gradually migrate toward it.

One early attempt to achieve native-like speed in the web browser using JavaScript was asm.js. Although that goal was reached and asm.js was adopted by all the major browser vendors, it never achieved widespread adoption by developers. The beauty of asm.js is that it still runs in most browsers, even in those that do not optimize for it. The idea behind asm.js was that typed arrays could be used in JavaScript to fake a C++ memory heap. The browser simulates pointers and memory allocation in C++, as well as types. A well-designed JavaScript engine can avoid dynamic type checking. Using asm.js, browser makers could get around many of the optimization problems created by the dynamic nature of JavaScript, by just pretending that this version of JavaScript is not dynamically typed. Emscripten, designed as a C++-to-JavaScript compiler, quickly adopted asm.js as the subset of JavaScript that it would compile to because of its improved performance in most browsers. The performance improvements driven by asm.js lead the way to WebAssembly. The same engine modifications used to make asm.js perform well could be used to bootstrap the WebAssembly MVP. Only the addition of a bytecode-to-bytecode compiler was required to take the WebAssembly bytecode and directly convert it into the IR bytecode used by the browser.

Emscripten is the tool we will be using to compile C++ into WebAssembly. Before I discuss Emscripten, I need to explain a technology called LLVM and its relationship to Emscripten.

First, take a moment to think of airlines (stay with me here). Airlines want to get passengers from one airport to another airport. But it's challenging to offer a direct flight from every single airport to every other airport on Earth. That would mean that airlines would have to provide a vast number of direct flights, such as Akron, Ohio to Mumbai, India. Let's travel back in time to the 1990s—that was the state of the compiler world. If you wanted to compile from C++ to ARM, you needed a compiler capable of compiling C++ to ARM. If you needed to compile from Pascal to x86, you needed a compiler that could compile from Pascal to x86. These are like having only direct flights between any two cities: a compiler for every combination of language and hardware. The result is either that you have to limit the number of languages you write compilers for, limit the number of platforms you can support with that language, or more likely, both.

In 2003, a student at the University of Illinois named Chris Lattner wondered, "What if we created a hub-and-spoke model for programming languages?" His idea led to LLVM, which originally stood for "Low-Level Virtual Machine." The idea was that, instead of compiling your source code for any possible distribution, you compile it for LLVM. There are then compilers between the intermediate language and your final output language. In theory, this means that if you develop a new target platform on the right side of the following diagram, you get all languages on the left side right away:

WebAssembly binary is not a language, but a build target similar to building for ARM or x86. The bytecode, however, is structured differently than other hardware-specific build targets. The designers of the WebAssembly bytecode had the web in mind. The aim was to create a bytecode that was compact and streamable. Another goal was that the user should be able to do a "view/source" on the WebAssembly binary to see what is going on. WebAssembly text is a companion code to the WebAssembly binary that allows the user to view the bytecode instructions in a human-readable form, similar to the way an assembly language would let you see what opcodes execute in a machine-readable form.

WebAssembly text may initially look unfamiliar to someone used to writing assembly for hardware such as ARM, x86, or 6502 (if you're old school). You write WebAssembly text in S-expressions, which has a parentheses-heavy tree structure. Some of the operations are also strikingly high level for an assembly language, such as if/else and loop opcodes. That makes a lot more sense if you remember that WebAssembly was not designed to run directly on computer hardware, but to download and translate into machine code quickly.

Another thing that will seem a little alien at first when you are dealing with WebAssembly text is the lack of registers. WebAssembly is designed to be a virtual stack machine, which is an alternative to a register machine, such as x86 and ARM, with which you might be familiar. A stack machine has the advantage of producing significantly smaller bytecode than a register machine, which is one good reason to choose a stack machine for WebAssembly. Instead of using a series of registers to store and manipulate numbers, every opcode in a stack machine pushes values on or off a stack (and sometimes does both). For example, a call to i32.add in WebAssembly pulls two 32-bit integers off the stack, adds them together, then pushes their value back on to the stack. The computer hardware can make the best use of whichever registers are available to perform this operation.

Now that we know what LLVM is, we can discuss Emscripten. Emscripten was developed to compile LLVM IR into JavaScript, but has recently been updated to compile LLVM into WebAssembly. The idea is that, when you get the LLVM compiler working, you can have the benefit of all the languages that compile to LLVM IR. In practice, the WebAssembly specification is still in its early days and does not support common language features such as GC. Therefore, only non-GC languages such as C/C++ and Rust are currently supported. WebAssembly is still in the early MVP phase of its development, but the addition of GC and other common language features are coming soon. When that happens, there should be an explosion of programming languages that will compile to WebAssembly.

When Emscripten was released in 2012, it was intended to be an LLVM-to-JavaScript compiler. In 2013, support was added for asm.js, which is a faster, easily optimized subset of the JavaScript language. In 2015, Emscripten began to add support for LLVM-to-WebAssembly compiling. Emscripten also provides a Software Development Kit (SDK) for both C++ and JavaScript that provides glue code to give users better tools for interaction between JavaScript and WebAssembly than those currently offered by the WebAssembly MVP alone. Emscripten also integrates with a C/C++-to-LLVM compiler called Clang, so that you can compile your C++ into WebAssembly. In addition, Emscripten will generate the HTML and JavaScript glue code you need to get your project started.

I am going to keep this section brief because these instructions are subject to change. You can supplement these instructions with the official Emscripten download and install instructions found on the Emscripten website: https://emscripten.org/docs/getting_started/downloads.html.

We will need to download and build Emscripten from the emsdk source files on GitHub. First, we will walk through what to do on Windows.

Python 2.7.12 or higher is a prerequisite. If you do not have a version of Python higher than 2.7.12 installed, you will need to get the windows installer from python.org and install that first: https://www.python.org/downloads/windows/.

If you have Git installed already, cloning the repository is relatively simple:

1. Run the following command to clone the repository:

git clone https://github.com/emscripten-core/emsdk.git

2. Wherever you run this command, it will create an emsdk directory. Enter that directory using the following:

cd emsdk

You may not have Git installed, in which case, the following steps will bring you up to speed:

1. Go to the following URL in a web browser: https://github.com/emscripten-core/emsdk.
2. You will see a green button on the right-hand side that says Clone or download. Download the ZIP file:

3. Unzip the downloaded file to the c:\emsdk directory.
4. Open up a Windows Command Prompt by typing cmd into the start menu and pressing Enter.
5. From there, you can change to the c:\emsdk\emsdk-master directory by typing the following:

 cd \emsdk\emsdk-master

At this point, it does not matter whether you had Git installed or not. Let's move forward:

1. Install emsdk from the source code running the following command:

emsdk install latest

2. Then activate the latest emsdk:

emsdk activate latest

3. Finally, set up our path and environment variables:

emsdk_env.bat

If you are installing on Ubuntu, you should be able to use the apt-get package manager and git for the complete install. Let's move forward:

1. Python is required, so if you do not have Python installed, be sure to run the following:

sudo apt-get install python

2. If you do not already have Git installed, run the following:

sudo apt-get install git

3. Now you will need to clone the Git repository for emsdk:

git clone https://github.com/emscripten-core/emsdk.git

4. Change your directory to move into the emsdk directory:

cd emsdk

5. From here, you need to install the latest version of the SDK tools, activate it, and set your environment variables:

./emsdk install latest
./emsdk activate latest
source ./emsdk_env.sh

6. To make sure everything was installed correctly, run the following command:

emcc --version

We run Emscripten from the command line; therefore, you can use any text editor you choose to write your C/C++ code. Personally, I am partial to Visual Studio Code, which you can download here: https://code.visualstudio.com/download.

One beautiful thing about Visual Studio Code is that it has a built-in command-line terminal, which lets you compile your code without switching windows. It also has an excellent C/C++ extension that you can install. Just search for C/C++ from the extensions menu and install the Microsoft C/C++ Intellisense extension.

Whatever you choose for your text editor or integrated development environment, you need a simple piece of C code to test out the emcc compiler.

1. Create a new text file and name it hello.c.
2. Type the following code into hello.c:

#include <emscripten.h>
#include <stdlib.h>
#include <stdio.h>

int main() {
    printf("hello wasm\n");
}

3. Now I can compile the hello.c file into WebAssembly and generate a hello.html file:

emcc hello.c --emrun -o hello.html

4. The --emrun flag is necessary if you want to run the HTML page from emrun. This flag adds code that will capture stdout, stderr, and exit in the C code and emrun will not work without it:

emrun --browser firefox hello.html

Running emrun with the --browser flag will pick the browser where you would like to run the script. The behavior of emrun seems to be different between browsers. Chrome will close the window when the C program exits. That can be annoying because we are just trying to display a simple print message. If you have Firefox, I would suggest running emrun using the --browser flag.

To find out what browsers are available to you, run the following:

emrun --list_browsers

emrun should open an Emscripten-templated HTML file in a browser.

Make sure you have a browser capable of running WebAssembly. The following versions of the major browsers should work with WebAssembly:

• Edge 16
• Firefox 52
• Chrome 57
• Safari 11
• Opera 44

Creating an installation guide for Emscripten is going to be somewhat problematic. The WebAssembly technology changes frequently and the installation process for Emscripten may be different by the time you read this. I would recommend consulting the download and install instructions on the Emscripten website if you have any problems: https://emscripten.org/docs/getting_started/downloads.html.

You may also want to consult the Emscripten page on GitHub: https://github.com/emscripten-core/emsdk.

Google Groups has an Emscripten discussion forum where you may ask questions if you are having installation problems: https://groups.google.com/forum/?nomobile=true#!forum/emscripten-discuss.

You can also contact me on Twitter (@battagline), and I will do my best to help you: https://twitter.com/battagline.

In this chapter, we learned what WebAssembly is and why it will be the future of application development on the web. We learned why we need WebAssembly, even though we already have a robust language like JavaScript. We learned why WebAssembly is so much faster than JavaScript, and how it has the potential to increase its performance lead. We have also discussed the possibility of WebAssembly replacing JavaScript as the de facto standard for application development on the web.

We have discussed the practical side of creating a WebAssembly module as it is done today using Emscripten and LLVM. We have talked about WebAssembly text and how it is structured. We have also discussed using Emscripten to compile our first WebAssembly module, as well as using it to create the HTML and JavaScript glue code to run that module.

In the next chapter, we will go into further detail on how to use Emscripten to create our WebAssembly module, as well as the HTML/CSS and JavaScript used to drive it.