DEV Community: DJ Hemath

Components of WebAssembly

DJ Hemath — Thu, 23 Jan 2025 03:30:00 +0000

Hey makkals,

This post is a part of a multi-part series on WebAssembly. Check out other parts of the series here

Now that we have a good idea about what WebAssembly is, it's time to understand the architecture that powers such a technology. WebAssembly comprises the following key components,

Module
Execution environment
Stack machine
Memory
Tables

WebAssembly Module

A WebAssembly module is a compiled unit of code that contains functions, memory, tables and other resources required for running a piece of code. Each module is self-contained and can be instantiated independently.

A module is essentially a file with the .wasm extension.

Modules can import and export functions and memory. This enables modular programming and seamless integration with other web technologies.

WebAssembly Execution Environment

WebAssembly relies on a sandboxed execution environment. It ensures secure and isolated code execution. This sandboxed environment is embedded within a host. The great thing about this is that a host can be a browser or NodeJS environment.

This sandboxed environment ensures security by restricting access to the host system. WebAssembly environments are closed by default. If a resource needs to be accessed, it should be explicitly requested.

The execution environment includes a WebAssembly runtime, which is responsible for,

Loading modules
Verifying modules
Managing memory
Executing instructions

Stack machine

WebAssembly operates as a stack-based virtual machine. All the instructions are executed by this virtual machine. It uses stack data structure to manage data and the control flow during the execution.

A stack machine uses a stack data structure where instructions are pushed and popped during execution. Let's take a look at a simple example,

(
    func $add(param $a i32) (param $b i32) (result i32)
        local.get $a
        local.get $b

        i32.add
)

The above example does the following,

Defines a function named add
The function takes 2 integers of 32-bits as parameter - a and b
Adds a and b
Returns the value of addition as a 32-bit integer

The stack machine executes the instructions in the following order,

Initially the stack is empty
Put the value of $a in the stack
Put the value of $b in the stack
Pop both $a and $b, perform 32-bit integer addition operation
Put the result in the stack

And whatever is left in the stack is the return value of the function.

Memory

One of the essential components that makes WebAssembly interoperable is its memory model. WebAssembly follows a linear memory model. It is a contiguous, growable array of bytes. It is a one-dimensional array used for storing data. This is the HEAP memory for WebAssembly programs.

It is indexed using byte offsets. It allows direct access to specific locations.

For example: Let's say we store two 8-bit numbers (say 10 and 16) in the memory. Since 8 bits equal 1 byte, the addresses of the numbers will be as follows,

10 - address 0
16 - address 1

Both of these integers necessarily need not to be exactly right next to each other. They can be in any location within the memory. But they can be accessed with the offset.

There can be any bits of data defined in the memory. It all comes down to the type of view we read the data.

It is not good to read a memory in an 8-bit view when the data defined are in 32-bit. It will produce unnecessary results. So it is better to stick with one view of memory to avoid unnecessary conflicts.

In JavaScript, we can access the memory with WebAssembly.Memory interface. To define a piece of memory from JavaScript, we can instantiate the Memory class like following,

const memory = new WebAssembly.Memory({
  initial: 10,
  maximum: 100,
});

The above code provisions 10 pages of memory. Generally in WebAssembly, 1 page of memory equals 64kB. In the above example, we provision 64 x 10 = 640kB of memory as minimum. Since the memory can be grown as needed, the maximum set is 64 x 100 = 6.4mB of memory.

We can also create shared memory with JavaScript. By creating a shared memory, we can allow multiple threads to access and manipulate the same memory.

The easiest way to set or get a value from WASM memory is to use two runtime methods you can export during compilation,

setValue(ptr, value, type)
getValue(ptr, type)

Let's see a simple example to understand the usage of memory from JavaScript to C. I borrowed this example from one of my favourite resource.

void addOne(int* input_ptr, int* output_ptr){
    *output_ptr = (*input_ptr) + 1;
}

In the above code, the function addOne receives two pointers. It then gets whatever the value in the input_ptr and adds 1 to it. And it sets the resultant value to another pointer named output_ptr.

In JavaScript,

var addOne = Module.cwrap("addOne", null, ["number", "number"]);

function main(){
    // alloc 4 bytes of memory for the input and 4 for the output (32-bit integers)
    var input_ptr = Module._malloc(4);
    var output_ptr = Module._malloc(4);

    var value = 6;

    // set the value in WASM memory
    Module.setValue(input_ptr, value, "i32");

    // call the WASM function
    addOne(input_ptr, output_ptr);

    // extract the result from WASM memory
    var result = Module.getValue(output_ptr, "i32");

    console.log("The result read is", result, "at position", output_ptr);

    // deallocate memory to avoid memory leaks
    Module._free(input_ptr);
    Module._free(output_ptr);
}

main()

The above code does,

Allocate two new memory locations in the heap and get pointers to them (malloc).
Set the value of the input writing directly to that memory position (setValue).
Call the C function to perform our calculation.
Access the output value stored in the memory (getValue).
Free the memory in the heap (free).

Note that we are explicitly de-allocating the memory at the end using the free method. Even though JavaScript has a garbage collector, C doesn't have one. So anytime we allocate something, we have to remember to de-allocate it.

Also, memory always needs not to be imported from JavaScript. A WebAssembly module can define its own memory. The syntax is different for each language.

Tables

WebAssembly tables are a separate memory segment (not included in the memory we discussed above) that stores the references to functions in WASM. It enables dynamic function calls.

Dynamic function calls means invoking a function indirectly through a reference or index stored in a table, instead of calling it directly by name or address. In WebAssembly, this is achieved using tables and the call_indirect instruction.

This enables calling functions in runtime without knowing the function beforehand. We don't need to know the exact function name. All we need is the memory address or the index of the function in the WASM table.

For example, let's say we are building a game. The game lets users modify skins of characters and objects.

In this case, users can download any skin and add to the game. We will never know what all the functions are inside the new skin plugin. But our game engine should be able to call the necessary functions. This is where tables help us.

Let's say our game expects three skin methods,

head() - to get the details of head like shape, color, eye color, etc.,
hands() - to get the information related to hands
shoes() - to get the information related to shoes

Our game instead of calling these functions with names, it instead calls with index. And our game expects that the shader or skin plugin stores the respective functions in the specified order in WASM tables.

Example, our game expects code related to,

head in the index 0
hands in the index 1
shoes in the index 2

Now the plugin can define any number of functions. It doesn't matter what the names of these functions are. But there should be a proper WASM table implemented in the same order.

Then our original game can blindly call these functions via reference via index and things should work seamlessly.

Conclusion

That is the high-level information about the major components of WebAssembly. Note that this is a beginner guide, so the examples and the definition are intentionally kept simple. We can do much more with these components which are all not mentioned here.

There are a lot of resources out there on the internet about these individual components in detail.

Some of my favourite ones are,

WASM tutorial by Marco Selvatici
MDN's WebAssembly documentation
WASM by example

So far, we've covered the foundational theory of WebAssembly. Now it's time to build some projects with real values.

Why WebAssembly is faster than JavaScript

DJ Hemath — Wed, 22 Jan 2025 03:30:00 +0000

Hey makkals,

This post is a part of a multi-part series on WebAssembly. Check out other parts of the series here

Originally published - https://hemath.dev/blog/webassembly/why-webassembly-is-faster-than-javascript

Alright, you might now be wondering why exactly WebAssembly is faster than JavaScript. And that's the question we are gonna answer in this post.

How is JavaScript executed?

Before we can understand how WebAssembly is faster, we need to understand how JavaScript is executed under the hood. Take a look at the following diagram.

The above chart explains the steps involved in executing JavaScript code. Each bar represents the relative time taken between each process.

NOTE: This is not an exact representation. It differs from browser to browser and the amount of JavaScript loaded in the page
But it gives a high-level idea about all the steps involved.

Each bar represents time taken for each step:

Parsing

Parsing is the process of converting text JavaScript code into an AST. This step takes place after the JavaScript is downloaded by the browser. Representing the JavaScript code as an AST tree helps the interpreter to execute the JavaScript code.

Compiling + optimizing

Modern browsers these days have a just-in-time compiler that compiles JavaScript. It's not technically a static compilation like it's done on C and other compiled languages. Instead the compiler assumes the types of parameters and returns types based on the usage. It then compiles it and keeps it in the memory for reuse. It results in a better optimized execution

Re-optimizing

However these assumptions are not always right. Sometimes a function can get/return different value types. In such cases, the JIT compiler throws away the existing optimized version and re-compiles it.

Execution

Execution is step where the JavaScript code is converted to executable instructions followed by executing the code line by line

Garbage collection

In this step, unused memory will be cleaned up by the built-in garbage collector. This adds an extra bit of overhead to the JavaScript's execution since the garbage collector keeps checking what memory objects need to be cleaned up.

How is WebAssembly executed?

After downloading the WASM file, it goes through only 3 steps instead of 5 steps.

Decode

Similar to parsing JavaScript. But WASM doesn't need to be converted into any structures. So after decoding, the integrity of the module is validated. After the validation, the WASM is ready to be executed.

Compiling + optimizing

WebAssembly code starts off much closer to the machine code. So compiling and optimizing WebAssembly is quicker than JavaScript. Since it is statically typed, the compiler doesn't need to spend time running the code to observe the usage of types.

Moreover, many optimizations are already done in the build step. So less work is needed to compile and optimize it.

Execution

Since compilers already produced the set of instructions, execution is a lot faster than JavaScript.

Conclusion

referred from Lin Clark's post

WebAssembly is faster than JavaScript in many cases because:

fetching WebAssembly takes less time because it is more compact than JavaScript, even when compressed.
decoding WebAssembly takes less time than parsing JavaScript.
compiling and optimizing takes less time because WebAssembly is closer to machine code than JavaScript and already has gone through optimization on the server side.
re-optimizing doesn't need to happen because WebAssembly has types and other information built in, so the JS engine doesn't need to speculate when it optimizes the way it does with JavaScript.
executing often takes less time because there are fewer compiler tricks and gotchas that the developer needs to know to write consistently performant code, plus WebAssembly's set of instructions are more ideal for machines.
garbage collection is not required since the memory is managed manually.

And, This is why, in many cases, WebAssembly will outperform JavaScript when doing the same task.

Build your first webassembly project

DJ Hemath — Tue, 21 Jan 2025 03:30:00 +0000

Hey makkals,

This post is a part of a multi-part series on WebAssembly. Check out other parts of the series here

Have you ever heard about WebAssembly and thought, "That sounds cool, but it's probably too complex for me"?

Well, today you're going to build a simple WebAssembly project from scratch. Let me set the right expectations. We are going to build a very simple project which generates random hexadecimal color code.

Think of it as the “Hello, World!” of WebAssembly with a splash of color. By the end, you'll learn how to write simple WebAssembly code, compile it, and use it with JavaScript to generate random colors right in your browser.

Setup WebAssembly

In this blog post series, we will be using C and C++ for examples. So we will be using a tool called Emscripten to compile our C / C++ code to WASM. However, you can use any supported language with the respective compiling tools.

Setting up Emscripten is straightforward. Just follow this page - https://emscripten.org/docs/getting_started/downloads.html

If you're using macOS, you can simply use homebrew to install it,

brew install emscripten

If you're using linux, follow this post - https://marcoselvatici.github.io/WASM_tutorial/#install_emscripten

After setting up Emscripten, you should be able to run the following command in your terminal,

emcc -v

Simple addition

Before implementing a random hex code generator, let's build something simple first to understand the WASM workflow. Let's build an application that just adds 2 numbers.

We will first build the application in JavaScript and then it into WASM later. Create a file named index.html and paste the following code,

<body>
  <input type="number" id="num1" placeholder="Enter first number">
  <input type="number" id="num2" placeholder="Enter second number">
  <button onclick="addNumbers()">Add</button>
  <p id="result"></p>

  <script>
    function addNumbers() {
      const num1 = parseInt(document.getElementById('num1').value);
      const num2 = parseInt(document.getElementById('num2').value);
      const result = addTwoNumbers(num1, num2);
      document.getElementById('result').textContent = `Result: ${result}`;
    }

    function addTwoNumbers(num1, num2) {
        const result = num1 + num2;
        return result;
    }
  </script>
</body>

The code is self-explanatory. On clicking the button, we get 2 numbers from the input fields and pass it to addTwoNumbers function. And the function returns a number which we display inside a paragraph.

Now let's move the addTwoNumbers function to C language. Create a file named add.c and write the following piece,

// add.c
int addTwoNumbers(int num1, int num2) {
    return num1 + num2;
}

Now, let's compile the C code to WASM,

emcc add.c -o add.js -s EXPORTED_FUNCTIONS="['_addTwoNumbers']" -s "EXTRA_EXPORTED_RUNTIME_METHODS=['ccall', 'cwrap']"

Let's breakdown what this command does,

emcc add.c -o add.js - Tells the Emscripten compiler to compile the C code from add.c to JavaScript in a file named add.js
-s EXPORTED_FUNCTIONS="['_addTwoNumbers']" - Tells the compiler to export the addTwoNumbers function so it can be used in JavaScript. The underscore (_) is part of the command, not part of the function name.
-s "EXTRA_EXPORTED_RUNTIME_METHODS=['ccall', 'cwrap']" - Tells the compiler to export additional runtime functions - cwrap and ccall are the functions that we use to wrap a C function and call it from JavaScript respectively.

After successful compilation, 2 new files would be generated - add.wasm and add.js. Here,

add.wasm is the actual WASM binary file that the browser will run.
add.js is just a glue-code that lets us use the functions defined in the C language seamlessly.

And change the HTML file as follows,

<body>
    <input type="number" id="num1" placeholder="Enter first number">
    <input type="number" id="num2" placeholder="Enter second number">
    <button onclick="addNumbers()">Add</button>
    <p id="result"></p>

    <!-- Including the JavaScript glue-code file generated by Emscripten -->
    <script src="./add.js"></script>

    <script>
      // Wrap the function provided by C
      const addTwoNumbers = Module.cwrap("addTwoNumbers", "number", ["number", "number"]);

      function addNumbers() {
        const num1 = parseInt(document.getElementById('num1').value);
        const num2 = parseInt(document.getElementById('num2').value);

        // Calling the wrapped function
        const result = addTwoNumbers(num1, num2);

        document.getElementById('result').textContent = `Result: ${result}`;
      }
    </script>
  </body>

Here, Module.cwrap is used to wrap the C function, so that we can use it as a normal JavaScript function.

cwrap takes three parameters,

function name - addTwoNumbers
return type - number
types of parameters - [number, number]

Run the application from a local server. If you don't have a local server installed in your machine, try any one of the following.

If you have Python 3 installed, try these,

python -m http.server

python3 -m http.server

Or, if you have NodeJS installed, try the following,

npm i -g live-server

and run the following command in the directory which contains the all the files that we have created now,

live-server

If everything went well, you will be able to see 2 input fields. Try entering 2 numbers and click the button to see the result.

Here, all the DOM manipulations such as event listeners, getting value from inputs, displaying result are done by JavaScript. Whereas, the addition is done by WASM which was written in C language.

You can find the full code for this project - here

Now let's start working on our actual project - random hexadecimal color generator

What is hexadecimal?

Before building our project, let's understand what is hexadecimal and how it can be represented as colors.

Hexadecimal is a number system with base 16. It means, the number system contains 16 symbols to represent values. The possible hexadecimal symbols are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, followed by A, B, C, D, E, F.

Here, A = 10, B = 11 and so on..

We can use hex code to represent colors with six digits. For example, #FF5733 or #42A5F5

To understand more about colors and their representation, read - Understanding Hexadecimal Colors.

Random color generator

Let's write our C code first. Create a file named random_color.c

We need to use two libraries: stdlib.h and time.h,

// random_color.c

#include <stdlib.h>
#include <time.h>

We define the generateRandomHexColor function, which returns a character pointer.

char* generateRandomHexColor() {
    // ...
}

Let's define necessary variable we need, and initiate random seed

char* generateRandomHexColor() {
    static char color[8]; // Store the color as a string (e.g., "#A3B2C7")

    srand(time(NULL));

    color[0] = '#';
}

We can use the rand function to generate a random number between 0 and 255. Then we need to convert it into a hexadecimal digit (i.e., 0 - 9 and A - F).

Let's first write an util function that converts an integer into a valid hex value,

char* intToHex(int num) {
    static char hexStr[3]; // Store the hex string (2 characters + null terminator)
    const char hexDigits[] = "0123456789ABCDEF";

    hexStr[0] = hexDigits[(num >> 4) & 0xF]; // High nibble
    hexStr[1] = hexDigits[num & 0xF];         // Low nibble
    hexStr[2] = '\0';                         // Null terminator

    return hexStr;
}

char* generateRandomHexColor() {
    // ...
}

Now we can use this intToHex function to convert our random numbers into hex code. The final code is,

// random_color.c

#include <stdlib.h>
#include <time.h>

char* intToHex(int num) {
    static char hexStr[3]; // Store the hex string (2 characters + null terminator)
    const char hexDigits[] = "0123456789ABCDEF";

    hexStr[0] = hexDigits[(num >> 4) & 0xF]; // High nibble
    hexStr[1] = hexDigits[num & 0xF];         // Low nibble
    hexStr[2] = '\0';                         // Null terminator

    return hexStr;
}

char* generateRandomHexColor() {
    static char color[8]; // Store the color as a string (e.g., "#A3B2C7")

    srand(time(NULL));

    color[0] = '#';

    char* r = intToHex(rand() % 256);
    color[1] = r[0];
    color[2] = r[1];

    char* g = intToHex(rand() % 256);
    color[3] = g[0];
    color[4] = g[1];

    char* b = intToHex(rand() % 256);
    color[5] = b[0];
    color[6] = b[1];

    color[7] = '\0'; // Null terminator to make it a valid string

    return color;
}

Now let's compile it to WASM,

emcc random_color.c -o random_color.js -s EXPORTED_FUNCTIONS="['_generateRandomHexColor']" -s "EXTRA_EXPORTED_RUNTIME_METHODS=['ccall', 'cwrap', 'UTF8ToString']"

And let's prepare a HTML file to use this function,

<body>
  <h1>Random Background Color</h1>
  <button onclick="changeBackgroundColor()">Generate Random Color</button>

  <script src="random_color.js"></script> <!-- Include the generated glue code -->

  <script>
    function changeBackgroundColor() {
      // Wrapping the function written in C
      const generateRandomHexColor = Module.cwrap("generateRandomHexColor", "number", []);

      const colorPtr = generateRandomHexColor();
      const color = Module.UTF8ToString(colorPtr);
      document.body.style.backgroundColor = color;
    }
  </script>
</body>

If everything goes well, you should be able to click a button that changes the background color of the page.

It's totally okay if don't understand how we get the color from pointer and how C's pointers are accessible via JavaScript. We will see more about WebAssembly architecture and memory in the upcoming posts.

You can find the full code for this project - here

Conclusion

In this post, we've taken our first steps in WebAssembly by writing simple C code, compiling it into WASM using Emscripten, and integrating it with JavaScript to build a functional random color generator. While this project is just the beginning, it shows the power and flexibility of WebAssembly in bringing high-performance code to the web.

With WebAssembly, you can unlock new possibilities for building faster, more efficient web applications. In future posts, we'll explore more advanced use cases, like image processing, to further understand how WebAssembly can enhance performance and extend JavaScript's capabilities.

Stay tuned for more hands-on examples and deeper dives into WebAssembly

WebAssembly - a beginners guide

DJ Hemath — Mon, 20 Jan 2025 03:30:00 +0000

Hello makkals,

It's been a while since I jumped in WebAssembly. I fell in love with the idea of WebAssembly. Built and worked in some cool projects. Now I decided share my knowledge with you all. This is going to be a series of blog posts that dives into many topics involving WebAssembly. At this point, I really don't know how many posts are going to be published. My rought guestimate tells at least 5 posts, but it may grow.

Nevertheless, worry not, I'll keep updating the this post with links of all the upcoming ones. This post is going to serve as an index for all other posts.

Almost every post is going to be practical-first so that everyone can understand the underlying theory by seeing clear examples.

Introduction to WebAssembly
Build your first ever WebAssembly project
Why WebAssembly is faster than JavaScript
Components of WebAssembly
Building a simple image processor using WebAssembly
Building a video to gif convertor with ffmpeg using WebAssembly

You can find code for all the projects we build in this repository

NOTE: This is a beginners guide to get started with WebAssembly. So it doesn't include granular details of every concepts in WebAssembly. It's a collection of all the knowledge that I attained so far in the WebAssembly.

Introduction to WebAssembly

DJ Hemath — Mon, 20 Jan 2025 03:30:00 +0000

Hey makkals,

This post is a part of a multi-part series on WebAssembly. Check out other parts of the series here

WebAssembly, or WASM for short, is a low-level assembly-like language. It lets us run applications built with different programming languages in the browser. It's a truly cross-platform way to build applications. It is low-level so that it runs at near-native speed enabling us to do a lot more on the web that weren't possible with just JavaScript.

If you’ve ever wished your web apps could run faster or handle tasks that seem too heavy for JavaScript, WebAssembly is here to help. In this post, we’ll break down what WebAssembly is, why it was created, and how you can start using it.

What is WebAssembly actually?

WebAssembly is a low-level compilation target. It is designed to run in web browsers. It's not something that lets you directly run other languages. Instead, it specifies an assembly language-like structure which other languages can compile-to, thus the term "compilation target".

Let's understand this by a simple example,

int a = 1;
int b = 2;
int c = a + b;

The above C code produces the following Assembly instructions (or machine code),

mov eax, 1    ; Load 1 into register EAX
mov ebx, 2    ; Load 2 into register EBX
add eax, ebx  ; Add EAX and EBX, result in EAX

This in-turn produces following binary,

00000000000000000000000000000011

NOTE: The above output varies on the CPU architecture. It's just a simple example that helps you understand the idea.

We can see that the C code is transformed into Assembly code and further into binary. The binary is something that can be executed directly by the computer.

Now, let's alter this process a little bit. Instead of the C compiler producing standard Assembly code, let's say it produces something like this,

$a int
$b int
$c int

set $a 1
set $b 2
set $c = add $a $b

NOTE: This is a made up syntax to let you understand the idea easily. It's not a standard syntax for anything in the world of WASM. We will see the actual syntax of WASM in this post later.

Assume that all browsers (Chrome, Firefox, Safari, etc.) understand and execute the above syntax. Then this opens up a wide-variety of opportunities for us on the web.

Because like the C language, we can write compilers for other potential languages like C++, Rust, Go, etc., that produce the above output for the respective code. It means that we can basically run programs written in any language in any browser no matter what type of OS is, or what browser it is, we should be able to run anything in the browser. And this is so cool!

Since all the browsers are built by separate teams in separate tech stack, we need a specification that defines how WASM should be treated. That specification is called WebAssembly and it is defined by W3C. And already all major browsers support WebAssembly natively. It means, today, we can run applications written in many programming languages inside a web browser.

WebAssembly representation

WebAssembly can be represented in 2 formats,

WAT - WebAssembly Text, it's a textual format designed to help us debug and understand the code
WASM - WebAssembly module is a binary format that browser uses to execute the instructions

Both are one-to-one representations of each other. It means that we can convert WAT to WASM and WASM to WAT. So compiling from a language to either WASM or WAT is possible, and we can obtain one from another.

Now, let's understand the very basic syntax with our above example,

The following piece of code declares three 32-bit integer variables - a, b and c

(local $a i32)
(local $b i32)
(local $c i32)

Let's assign some values to these variables,

i32.const 1
set_local $a 

i32.const 2
set_local $b

Let's add a and b, and store it in c,

get_local $a
get_local $b

i32.add

set_local $c

If you don't understand the syntax intuitively, it's okay. WebAssembly is designed to run in a stack-machine. We will see more about stack machines in future posts. But for now, understand that a stack machine puts and pops instructions based on the instruction type.

So when we do, get_local $a and get_local $b, we are pushing both of them into the stack. And the instruction i32.add tells the browser to,

add the top 2 numbers in the stack
pop them out
keep the result of addition in the stack (in our example, it's the number 3)

And the set_local $c tells it to store whatever the value is in top of the stack to the variable $c.

This is the textual representation (WAT) representation of the code. When transpiled into WASM, it looks like this:

0x20 0x00    ;; get_local $a
0x20 0x01    ;; get_local $b
0x6A             ;; i32.add
0x21 0x02    ;; set_local $c

Don’t worry if these representations seem complex. WebAssembly is designed as a compilation target, not a language you need to write directly.

This is a compilation-target, not a programming language per se. Almost all the time we will write code in programming languages like C, C++, Rust, etc., and compile it into this representation.

Will WebAssembly replace JavaScript?

Short answer: No, at least not anytime soon. WASM is designed to work along with JavaScript, not to replace it. JavaScript and WebAssembly complement each other.

JavaScript was originally created for basic web operations like DOM manipulation and form validation. In the past decades, we wanted more from JavaScript and made it do certain things that it isn't designed for. The result is poor performance on complex applications. Since JavaScript is interpreted it is relatively slow compared to other compiled languages. However, modern web browsers have a JIT compiler which improves performance of JavaScript applications.

I might probably write a blog post about the JIT compiler soon. But before that you can follow one of my favorite blog posts on the topic - https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers

Even with JIT compilers, JavaScript can only do so much. That's where WebAssembly comes into the picture.

Let's say we want to process video files. Video files are generally large, and doing some operations with it like optimizing, editing, different codecs, etc., are very data intensive operations. Since JavaScript is interpreted and JIT compiled at its best, it cannot deliver native performance.

But with WebAssembly, we can achieve near-native performance since the code is pre-compiled and close to machine code, the execution will be pretty fast. So WebAssembly is just a new gym-rat friend for JavaScript. WebAssembly can do the heavy-lifting CPU intensive tasks very well while JavaScript can do the tasks (DOM manipulations, handling events) it was supposed to do.

Use cases of WebAssembly

WebAssembly’s near-native performance makes it ideal for computationally intensive applications.

Some of the use cases are,

Image processing
Video processing
Games - even 3d games
Music applications
Encryption and other cryptographic solutions
Visualization tools
Simulators and emulators
And existing applications like AutoCAD, etc.,

There are some applications that are already using WebAssembly are,

Figma - https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/
Amazon Prime - https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types
Google Earth - https://madewithwebassembly.com/showcase/google-earth/
Autodesk - https://forums.autodesk.com/t5/engineering-hub-blog/autodesk-open-sources-web-based-usd-viewing-implementation/ba-p/11071751
and many more..

You could and most probably will build WebAssembly applications in the near future.

WebAssembly - beyond the browser

WebAssembly was initially designed as a binary instruction format for executing native code efficiently within web browsers. However, its potential extends far beyond the browser.

Yes, you read it right. There is another project that was built with WASM as the basis known as WASI (WebAssembly System Interface). It is a group of standards API specifications for softwares that compile to the WASM standard.

We can build cross-platform applications and produce a single binary. Previously if we wanted to build a cross-platform application we had to build binaries for all the platforms and architectures (x86, arm, etc.,) that we needed to support. Or, we have a choice to use Java's virtual machine. By using Java, we are constrained within the Java ecosystem.

But WASI enables us to write code in any language, build a single binary file and just ship it! WASI runtimes are built for other platforms and architectures, so that we don't have to produce binaries for every platform and architecture combination.

It's so great that even Docker's founder posted a tweet saying that if WASI was invented in 2008, there is no need for Docker to be created in the first place.

Take a look at the tweet - https://x.com/solomonstre/status/1111004913222324225

We will look more about WASI in the upcoming posts.

Before WebAssembly

Before WebAssembly was invented there were multiple projects that focused on running other programming languages on the web. Some of them were successful to a point, while others failed. WebAssembly was designed to address the limitations of these projects while providing a standardized solution.

Some of those old projects are,

Microsoft's ActiveX - allowed embedding native code in Internet explorer, but there were some major security vulnerabilities
Java Applet's - Let the Java bytecode run in the browser, but it is required to install Java plugin in browsers. It also possessed some degree of security issues.
Adobe's Flash - It was a big hit and many people used it. It also came in the form of a plugin. It was a proprietary technology controlled by Adobe which had lack of standards and led to its decline
Google's Native client (NaCl) - Above 3 faced performance issues, while NaCl allowed near-native performances and supported multiple architectures. But it was limited to Chrome browsers and failed to gain wide adoption.
Firefox's asm.js - Firefox's effort to bring near-native performance to the web. It can be said that it's a direct successor of today's WASM. asm.js is also specified as a compilation target and compiled to a low-level, statically typed JavaScript. It enabled JIT compilers to execute fast as it was statically typed. But it was still slower than native code and produced large code sizes.
Google's Dart - Dart could be compiled to JavaScript or run natively in the Dart VM. But it never gained support in other browsers.
And some more like Silverlight, etc.,

All of these failed at some point mainly because of the lack of standards and poor performances in some cases. WebAssembly was designed to solve these problems by being standard, portable, secure, performant and extensible.

The fact that it was adopted as a W3C standard made all major browsers to support it natively. Previously independent companies came up with solutions and tried to integrate with their own browsers and hoped other browsers would implement. But almost all of them failed. By adopting WebAssembly as a W3C standard made it clear that all major browsers will support it.

Conclusion and next steps

That's it for this post. This post aimed to provide a high-level understanding of what WASM is and its capabilities. In the upcoming posts, we will dive deep into more topics and build some projects in WebAssembly.

Read the next post in this series - Build your first Webassembly project