Despite its name, WebAssembly (a.k.a Wasm) is not quite an assembly language. It’s not meant for any particular machine. It’s for web browsers, and when you’re delivering code to be executed in the browser, you don’t know what kinds of machines will your code be running on.
WASM is a new binary-based programming language you can run in a web browser. WASM is designed to be faster than JavaScript because it is a low-level language. That means that it is closer to machine code, which processors can execute more quickly.
What’s so unique about Wasm?
Wasm is faster. Unlike Javascript, WASM is statically typed, which means code optimization occurs far earlier in the compilation process before the code reaches the browser. Its binary files are considerably smaller than JavaScript’s, resulting in significantly faster loading times. Interestingly, Wasm is 1.15-1.67 times faster than JavaScript on Google Chrome on a desktop. Said that, Wasm is not intended to replace JavaScript, but to run alongside it. This way, developers can get a best-of-both-worlds for their applications.
Major benefits of using WebAssembly includes:
- Efficient and fast – Wasm bytecode is designed to be encoded in a size- and load-time-efficient
binary format - It’s safe: WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.
- It’s debuggable: WebAssembly is designed to be pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand.
- It’s part of open web platform: WebAssembly is designed to maintain the versionless, feature-tested, and backwards-compatible nature of the web.
- Platform-independent – It can help execute code efficiently and limit the risks of untrusted code being used within the ecosystem.
How does Wasm work in browsers?
Browser engines, such as Google Chrome’s V8 engine and Mozilla Firefox’s SpiderMonkey, include a WebAssembly (Wasm) virtual machine or runtime. This runtime is responsible for executing the Wasm binary instructions within the browser environment.
To enable running existing applications or codebases in the browser, compiler toolchains like Emscripten come into play. Emscripten is a popular toolchain that can compile source code written in languages like C, C++, or Rust into the Wasm target. It translates the code into a format that can be understood and executed by the Wasm runtime in the browser.
By using Emscripten or similar tools, developers can port legacy applications, libraries, or game engines written in languages like C or C++ to run in the browser. This allows them to leverage the power of native languages and reuse existing codebases while seamlessly integrating with client-side JavaScript code in web applications.
The Wasm runtime provides an interface that enables communication between the Wasm module and the JavaScript code running in the browser. This allows bidirectional data exchange, function calls, and interactions between the Wasm module and the surrounding JavaScript environment.
Overall, WebAssembly provides a standardized and efficient format for running code in the browser, allowing developers to leverage existing codebases and bring powerful applications to the web platform.
How does Wasm work on servers?
In addition to running within the browser, WebAssembly (Wasm) can also be executed outside of the browser environment. This is made possible by Wasm runtimes that are designed to function on traditional operating systems like Linux, Windows, and macOS.
When running Wasm applications outside of the browser, the Wasm runtime needs to communicate with the host system using interfaces other than the JavaScript engine. One such interface is the WebAssembly System Interface (WASI). WASI provides a standardized way for Wasm modules to interact with the host system, similar to how applications interact with the operating system through POSIX interfaces.
WASI allows Wasm modules to perform various system-related operations, such as file I/O, network access, and interacting with system resources. By leveraging WASI, Wasm runtimes enable Wasm applications to communicate with the host system in a secure and controlled manner.
To facilitate the porting of existing POSIX-compliant applications to WebAssembly, projects like WASI SDK and wasi-libc have been developed. WASI SDK provides a toolchain and set of development tools for compiling POSIX applications to the Wasm target, while wasi-libc is a C library implementation that provides the necessary POSIX-compatible functions and system calls for Wasm modules.
By using WASI SDK and wasi-libc, developers can compile their existing applications, written in languages compatible with POSIX standards, to WebAssembly. This allows them to take advantage of the cross-platform nature of WebAssembly while reusing their existing codebases and benefiting from the performance and security advantages offered by WebAssembly.
In summary, Wasm runtimes that operate outside of the browser, coupled with the WASI interface and supporting tools like WASI SDK and wasi-libc, enable Wasm applications to interact with the host system and bring the power of WebAssembly to traditional operating systems in a portable and efficient manner.
What about interpreted languages?
So far we have only mentioned compiled languages such as C and Rust can target WebAssembly. For interpreted languages such as Python, Ruby and PHP, the approach is different: their interpreters are written in C and can be compiled to WebAssembly. Then this interpreted compiled to Wasm can be used to execute the source code files, typically ending in .py, .rb, .php and so on. Once compiled to Wasm, any platform with a Wasm runtime will be able to run those interpreted languages even if the actual interpreter was never compiled for that platform natively.
