Chapter 5. Beyond the Browser
The main goal of WebAssembly was to allow the creation of high-performance applications on the web, using a range of programming languages. It was anticipated that people would use WebAssembly for video editing, CAD, Augmented Reality (AR)/Virtual Reality (VR) and various other computationally intensive tasks, and as we’ve seen in the previous chapters, this has been a success.
However, the WebAssembly specification was carefully designed to allow the integration into other, nonbrowser, environments. A WebAssembly module communicates with a host, but makes no assumptions about the nature of the hosting environment itself. The extent of WebAssembly adoption as a nonbrowser runtime has been greater than most initially envisaged. We cover some concrete examples later in this chapter, but first, let’s take a look at some of the features of WebAssembly that make it an appealing option as a runtime:
- Secure
-
Modules execute within a sandboxed environment that is separate from the host runtime. This provides isolation in the case of faulty or compromised code. Even though this is an important requirement for execution of code delivered over the web, there are many other contexts for which isolation is also required.
- Language and vendor independent
-
The WebAssembly specification was designed with a range of languages in mind, and while certain languages are easier to compile with the Minimum Viable Product (MVP) featureset, as new features such as garbage collection are added, language support will improve. Furthermore, WebAssembly is vendor agnostic, having been developed in collaboration by many vendors and technologists.
- Simple
-
WebAssembly doesn’t have a garbage collector, runtime APIs, reflection, or class loaders. This results in a simpler and more lightweight runtime, and also contributes to the overall security of the runtime (by reducing the attack surface).
- Fast
-
WebAssembly was primarily designed for delivery over the web, where the initial download and compilation time is just as important as the eventual runtime performance. Runtime features such as streaming compilation and fast/simple validation rules all contribute to fast start times and near-native performance.
WebAssembly is certainly not the first portable runtime; the Java Virtual Machine (JVM) is probably one of the most well-known and successful runtimes to date. However, its design goals were different from those of WebAssembly, and it doesn’t have the same simplicity, sandboxing, and language independence that the latter enjoys.
These features have contributed toward many experimenting with, and indeed adopting, WebAssembly as the runtime for a diverse range of applications. Let’s dig into just a few of the more notable applications of WebAssembly beyond the browser, and see how this technology might eventually deliver what Java’s famously promised: “Write Once, Run Anywhere.”
Serverless
Several companies are taking an interest in the use of WebAssembly as a runtime for serverless cloud functions, allowing them to provide runtimes with fast response times and reduced “cold starts” (the time taken to provision a new server or container in response to a request).
Cloud computing has experienced explosive growth over the past decade. The whole premise of this approach is that you relinquish control over various parts of your infrastructure (network, operating system, app server, containers) to the cloud provider who manages them on your behalf. The net result is potential cost savings (due to on-demand provisioning) and greater agility (due to having less infrastructure to manage yourself, coupled with automation).
Serverless computing is a relatively new concept in which you allow the cloud provider to manage everything, you just provide your code and they take care of provisioning the resources required to run it. For this reason, serverless is sometimes referred to as Function-as-a-Service (FaaS).
Despite the name (serverless), your function is actually running on a server somewhere, it is just that the cloud provider takes care of seamlessly provisioning a server when your function needs to be executed (e.g., in response to an HTTP request). At least that’s the promise; however, in practice it isn’t seamless. Anyone who has worked with a serverless architecture is familiar with the impact of cold start times when the cloud provider needs to provision a new server or container to handle a request. Subsequent requests are likely to be fulfilled by the same server, hence response time is greatly reduced. Depending on the underlying technology, cold start times can be as long as 10 seconds.
The entire reason why a server or container is required in order to execute your “cloud function” is security. It needs to be executed in isolation, protecting it from faults and vulnerabilities in other cloud functions that might be running on behalf of other customers. This is why several companies are taking an interest in the use of WebAssembly as a runtime for serverless cloud functions.
Cloudflare has published details of its new cloud computing platform called Workers (not to be confused with Web Workers), which is based on the Chrome V8 JavaScript engine concept of “isolates.” This is a much more lightweight serverless runtime when compared to the virtual machine or container-based approach that most public cloud providers use, as illustrated in Figure 5-1. The isolate runtime can execute JavaScript code but also hosts the WebAssembly runtime, allowing people to deploy cloud functions using a wide range of languages.
Figure 5-1. The isolate model for execution of serverless functions
This model has advantages both for the cloud provider, which is able to serve many more cloud functions with far fewer resources, and the end user, who sees significantly minimized cold-start time (Cloudflare report 5 ms versus 500 to 1,000 ms for AWS Lambda).
With the growing popularity of serverless architectures, other cloud and Content Delivery Network (CDN) providers are also exploring the use of WebAssembly as their runtime in order to reduce the virtualization overhead and provide faster cloud functions to their users.
Blockchain
Since the initial public release of WebAssembly there has been a growing interest in this technology from the blockchain community, with various cryptocurrency companies investigating its use as a runtime for executing smart contracts.
Blockchain is a decentralized ledger technology that uses a combination of cryptographic methods and a distributed consensus model to maintain its integrity. The Bitcoin network encodes and executes transactions using a simple scripting language. This language is limited and intentionally not Turing-complete—lacking loops, for example—making it deterministic and “safe.”
Following the early success of Bitcoin, the Ethereum network was launched in 2014. It is based around a similar set of core concepts—a decentralized, distributed ledger—but significantly enhanced the computing capability. With Ethereum, developers can write complex applications, called smart contracts, that are deployed to the blockchain network. These contracts are written in Solidity, an object-oriented language that was designed specifically for contract authoring, and are executed by the Ethereum Virtual Machine (EVM) that runs on the nodes within the network.
The features of the WebAssembly runtime (fast, lightweight, sandboxed) are ideal for a smart contract engine. It also removes the need for developers to learn a new language (Solidity), allowing them to write smart contracts using a wide range of different languages. The blockchain community hopes that this will attract a great many more developers to the platform.
Ethereum isn’t the only blockchain company investigating WebAssembly; there are a whole host of others betting on this technology, including Perlin, Tron, EOS, U°OS, Spacemesh, and many more. WebAssembly is showing signs of becoming the runtime of choice for the blockchain community.
Bytecode Alliance
The rapid adoption of WebAssembly across a range of industries and problem domains has resulted in the formation of a new industry body: the Bytecode Alliance. This group, founded by Mozilla, Red Hat, Intel, and Fastly has a broad mission:
Our mission is to provide state-of-the-art foundations to develop runtime environments and language toolchains where security, efficiency, and modularity can all coexist across a wide range of devices and architectures.
Modern software development is highly modular, with applications tending to use a large number of external dependencies from registries such as npm (Node.js package manager) and crates (Rust package repository). However, there has been a significant rise in security issues relating to third-party modules. One such example is an attempt to steal cryptocurrency via a compromised node module, although there are unfortunately a great many more examples. The Bytecode Alliance believe that the security model of WebAssembly, which allows isolation of third-party modules within its own sandbox, will significantly reduce the risks associated with using third-party code.
WebAssembly brings additional benefits beyond security; language interoperability is a common problem for many developers. If you’re a node developer who has used a native module (which requires machine-specific compilation as part of the installation process), or a Python developer using a C/C++ extension library, you’ll understand the friction this causes. The portability of WebAssembly, which will be enhanced further by interface types proposal, significantly reduces this friction, allowing seamless communication between modules written in different languages.
Finally, the development of a standard system interface (WASI) yields the possibility of running WebAssembly without the need for a host, making it a standalone runtime. Once again, the portability and isolation that the runtime offers are significant benefits for this use case. The team at the startup Wasmer has developed a WASI-enabled WebAssembly runtime, for people who want to create standalone WebAssembly applications. As the WASI standard evolves, you’ll be able to write increasingly complex applications using this approach, such as web servers.
Conclusion
The goal of this report is to give you a better understanding of why we need WebAssembly, what it is, how to use it, and where this technology is heading. Hopefully what you have read has piqued your interest and encouraged you to explore this new and exciting technology, using your language of choice!
As a closing remark, I’d like to reiterate that JavaScript was introduced 25 years ago. WebAssembly is the first universally supported new language and browser runtime to have been introduced since. With the ubiquity of the browser as a platform, this is certainly enough to make it a notable technology, and one to watch. However, WebAssembly has greater ambitions, as the runtime for blockchain, serverless computing, and perhaps as a runtime in its own right. Just as JavaScript started as a browser language but escaped the confines of the web, finding success on the server, mobile, and beyond, WebAssembly is gearing up to do the same.