WASM (WebAssembly )

WASM stands for WebAssembly, a low-level, binary instruction format designed to run efficiently on the web. It is a portable, lightweight, and fast format that enables high-performance execution of code in web browsers and other environments.

At its core, WebAssembly serves as a bridge between high-performance native code and web browsers. Think of it like a universal translator that allows programs written in languages like C++, Rust, or Go to run directly in web browsers without losing their speed advantages.

WHY WE NEED WASM???

let's look at a common scenario: Imagine we have a complex application written in C++ that performs intensive calculations, like a video editor or a 3D game engine. Before WASM, if we wanted to run this application in a web browser, we would need to completely rewrite it in JavaScript. This was often impractical because JavaScript, being an interpreted language, couldn't match the performance of compiled C++ code.

This is where WASM comes in. It allows developers to take their existing C++ code, compile it to WebAssembly, and run it directly in the browser at near-native speed. The compiled WASM code runs in a safe, sandboxed environment alongside JavaScript.

BUT HOW THIS WORKS 🤔

The main work of WebAssembly can be understood through its execution process:

First, it takes code written in languages like C++ , Rust or any other language and compiles it into a special binary format. This is similar to how a translator might take a book written in Chinese and convert it into a universal format that can be easily translated into any language. This binary format is highly optimized and designed to be read and executed very quickly by browsers.

When this compiled code reaches the browser, WebAssembly's virtual machine (which we can think of as a specialized reader) executes these instructions directly. It's like having a highly efficient worker who understands exactly what needs to be done without needing any further interpretation or translation.

To make this even clearer, here's what happens when WebAssembly runs in our browser:

1. The browser downloads the WebAssembly binary code.

2. This code is instantaneously validated to ensure it's safe to run.

3. The code is compiled into actual machine code that your computer can execute directly.

4. It runs in a sandboxed environment, meaning it can't directly access our computer's resources or memory outside its designated space.

5. It communicates with JavaScript when it needs to interact with the webpage or perform external operations.

What are the advantages of using WASM??

Performance: WASM code executes at near-native speed because it's compiled to binary format, making it much faster than interpreted JavaScript for computation-heavy tasks. For example, a complex physics simulation might run 10-20 times faster in WASM compared to pure JavaScript.

Language Flexibility: You can write code in languages like C++, Rust, or Go and compile them to WASM. This means you can reuse existing codebases and leverage the strengths of different programming languages. For instance, you might use Rust's memory safety features for critical components while still running them in the browser.

Code Reuse: Organizations can maintain a single codebase that runs both on native platforms and the web. Mozilla, for example, uses this approach with their Firefox DevTools - much of the code is written in Rust and compiled to both native binaries and WASM.

Security: WASM runs in a sandboxed environment with the same security constraints as JavaScript. It can't directly access the system's memory or resources outside its sandbox, making it safe for web deployment.

Is there any disadvantage of using WASM?

Limited DOM Access: WASM can't directly manipulate the webpage's DOM (Document Object Model). It needs to go through JavaScript for any webpage interactions, which can create a performance bottleneck in UI-heavy applications.

Learning Curve: Developing with WASM requires understanding compilation toolchains, memory management, and potentially new programming languages. This can be challenging for teams primarily experienced with JavaScript.

Binary Size: While WASM binary files are typically smaller than equivalent JavaScript, complex applications can still result in significant download sizes. A large WASM module might add several megabytes to your web application's initial load time.

Debug Complexity: Debugging WASM can be more challenging than JavaScript because you're working with compiled code. While tools are improving, they're not yet as mature as JavaScript debugging tools.