Solomon Hykes, co-founder of Docker, published a tweet claiming that “If WASM-WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is.”
Now and then, IT experts become enthusiastic about a new feature in web development. Currently, there’s a lot of buzz surrounding WebAssembly (WASM), a new method of delivering code to browsers and Internet of Things (IoT) devices. This is possible through the WebAssembly System Interface (WASI) and the WebAssembly Gateway Interface (WAGI), which enable access to browser devices and networking capabilities.
The impact of this technology is just starting to be revealed, and in this article, we aim to shed light on its key features, advantages, and disadvantages, and inspire you to try compiling your own applications to WebAssembly.
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust/C#, enabling deployment on the web for client and server applications.Source
The basic concept here is that you can compile code from other languages into WebAssembly format and run it on any browser or WASM-compatible device (IoT) without worrying about the underlying infrastructure.
Ah! It is a target for compilation… But what is it?
A compilation target is a platform or architecture for which code is compiled, including the operating system, processor architecture, and other specific details of the target platform. It’s possible to write WebAssembly code and also to compile it from other compatible languages. The result is a unique bytecode WebAssembly format that can run on any browser or WebAssembly-enabled environment for any architecture or device.
In practical terms, when code is compiled to WebAssembly, it is converted to the instruction set of a stack-based virtual machine and stored in a binary format in a .wasm file. The machine code is designed to be easily compiled to real processors, allowing the .wasm file to be ingested by a runtime, such as a browser or Node.js, and converted into actual machine code that can be executed safely.
But, wait a minute! Writing code in a language to be compiled into a browser executable application? It sounds familiar, right? Java applets, Flash, Silverlight? Despite the similarities, there are many good reasons to explore WebAssembly, but the main difference is that it runs natively on modern browsers with near-native performance, without the need for additional software or extensions. This is a major improvement compared to the experiences with Java, Flash, or Silverlight, where installations were often required to access websites or play games.
How does WebAssembly break into web platform
In an abstract way, we can represent the web platform with two major parts: a virtual machine (VM) that runs the web app’s code and a set of web APIs that web app’s can call in order to control the web browser (or any other device) functionality and “make the things happen”.
Where’s Docker stand?
Docker is a technology for wrapping up a program and its dependencies into a single package and then executing the application. Practically speaking, a Docker image is a set of snapshots of a file system. These snapshots are layered together to form a single environment that appears (to the application) to be a complete operating system. Docker images are lighter than virtual machine images. And when they are executed, Docker containers tend to require fewer system resources than virtual machines.
WebAssembly modules are compiled applications. Unlike Docker, a WebAssembly module does not come with a pre-packaged file system or other low-level operating system primitives. Instead, files, directories, environment variables, clocks, and other system resources can be attached directly to the WebAssembly module during startup on the browser.
Because the WebAssembly format is platform-neutral, one single binary can be compiled and then executed on a variety of operating systems and architectures. Unlike Docker images, it is not limited to just Windows and Linux. WebAssembly binaries are runnable on all major operating systems. They can run on x86, x64, ARM, and other processor architectures as well.
Containers have some real strengths. Existing programs can run unaltered in containers. Programs that rely on heavy IO with the file system and require high degrees of control over underlay architecture may find containers more friendly than the more stringent WebAssembly security sandbox. And most importantly, servers that require access to the sockets layer will thrive in the container world.
WebAssembly, on the other hand, is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages with low-level memory models, such as C++ and Rust, and high-level languages with garbage-collected memory models, like C# or GO. WebAssembly bytecode is not meant to be written by humans; we need a Wasm compiler to translate it. Luckily, most popular programming languages have their own Wasm compiler. You’ll find an updated list on github.com/awesome-wasm-langs
WebAssembly, on the other hand, gets passed to Liftoff, V8’s WebAssembly compiler.
Once that compiler is done, the same TurboFan kicks in and generates optimizing codes.
Now, there are some differences here: The obvious one is that the first stage has a different name and a different logo, but there’s also a conceptual difference, Ignition is the interpreter, and Liftoff is a compiler that generates machine codes. It would be an overgeneralization to say that machine code is always faster than interpreted code, but on average, it’s probably true.
Let’s see WebAssembly in action
We talked about how some big companies are using WebAssembly to bring their existing products, that they probably wrote in C++ or C, to the web. For example, that was the case with AutoCAD, a well-known product who had been working for years. Now they’ve put in the effort of compiling it to WebAssembly, and suddenly, with the same C++ code base, it was running in the browser. It’s mind-blowing to think about what we were capable of 5 or 6 years ago.
Another example would be the Unity game engine or the Unreal game engine, which now support WebAssembly. These game engines often already have a kind of abstraction built in because you build your game, and then you compile it to PlayStation, XBox, or other system. Now, WebAssembly is just another target, and what is impressive is that the browser and WebAssembly are able to deliver the performance necessary to run these kinds of games.
Browser-based Crypto Mining is now possible using WebAssembly binaries. Unethical for sure, but possible.
As a binary format for executing code in a web environment, WebAssembly poses some security challenges and risks, especially with regard to running untrusted code in the browser. However, the security of WebAssembly is also improved by several key features and practices:
- Sandboxing. It runs in a secure sandbox environment, isolated from the main web page, which helps to prevent attacks such as cross-site scripting (XSS) and cross-site request forgery (CSRF).
- Memory Safety. It has built-in memory safety features that prevent buffer overflows, which are a common source of security vulnerabilities.
- Validation. WebAssembly code is validated before it is executed, which helps to prevent malicious code from being executed.
- Limited API Access. It has limited access to the web browser APIs, which reduces the attack surface and helps to prevent malicious code from accessing sensitive information.
Despite these security features, developers still need to be cautious and follow best practices when developing and deploying WebAssembly code. This includes verifying the origin of the code, avoiding unsafe or untrusted APIs, and keeping the code and libraries up-to-date to address any potential security vulnerabilities.
WebAssembly provides improved security compared to traditional web development, but it is not immune to security risks. Developers must be aware of these risks and take appropriate measures to protect their users and applications.
Nice, but where’s the catch?
WebAssembly has many advantages for web development, but there are also some disadvantages and limitations to consider:
- Complexity. The source code is a binary format, considered low-level, which may pose difficulties for developers who are not familiar with Assembly language concepts.
- Compatibility. It is supported by modern web browsers, but not all browsers support it, which can limit its adoption and usability.
- Maturity. WebAssembly is a relatively new technology, and some of its features and capabilities may still be evolving, leading to potential compatibility issues.
Developers should consider both the advantages and limitations of WebAssembly when deciding whether to use it for a project. While WebAssembly provides many benefits for web development, it is important to be aware of its challenges and limitations.