What is WebAssembly?

WebAssembly provides a secure, fast, and efficient compilation target for a wide range of modern programming languages. WebAssembly’s simplicity as a runtime and sandbox environment lends to various use cases such as containers, blockchain and IoT.

The Web needed a new Programming Language

During JavaScript’s earlier years as a scripting language, interactions were limited to dynamic menus, button-clicked responses, and pop-up dialogs. JavaScript as a language experienced great growth in the pursuit of interactivity.

However, Javascript suffers in execution speed and performance predictability compared to compiled languages. JavaScript lacked the ability to advance browsers with features such as low-level networking, multithreaded code, graphics, and streaming video codecs. This limitation affected applications where performance is critical, such as video editing, CAD, and AI.

WebAssembly (wasm) serves to address some of JavaScript’s limitations. Wasm was designed as a compact compilation target to enhance performance for the web. In 2017 when WebAssembly was released, the WebAssembly working group stated,

“WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web.”

WebAssembly is an instruction-set architecture with low-level bytecode that runs on web browsers (and servers). WebAssembly serves as a compilation target for higher-level languages including C++, Rust, C, and Go.

Design Goals

WebAssembly was developed by a team called the W3C WebAssembly Community Group. This group included engineers from Mozilla, Google, Apple, Microsoft, and various other organizations. The W3C WebAssembly Community Group solidified key design goals as a foundation for WebAssembly in the project’s infancy. The team prioritized efficiency, portability, legibility, security, and compatibility.

The most significant of these goals include:

• Minimum Viable Product (MVP)
• Performance
• Security
• Independency

WebAssembly’s unique features inspired adoption for a range of applications. We will dig into notable features of WebAssembly beyond the browser.

Minimum Viable Product

Web specifications are generally developed through collaboration amongst multiple parties. Often this results in initial ideas slowly going through specification before implementation. To expedite the process, the initial WebAssembly specification was conceived as a Minimum Viable Product (MVP) with a number of specific use cases targeted for the MVP scope.

The MVP features met the needs of image processing, audio processing, computer aided design, games, and various other applications that are computationally intensive. The tooling developed around the MVP focused on the migration of existing applications, predominantly those written in C++. The MVP was not designed as a general-purpose web application development platform.

This focused approach ensured that WebAssembly was quickly released in just a few years. However, the initial release was missing certain features that could make it more broadly useful. More features have been and will continue to be released over time.

These design decisions have resulted in a technology that is rapidly loaded, decoded, and executed at near-native speed.

Performance

Initial download speed, compilation time, and runtime performance hold parallel importance for web technologies. With a size and load-time efficient binary, WebAssembly optimally utilizes common hardware capabilities to execute at near-native speed.

Historically, JavaScript design decisions hindered the language’s performance. While JavaScript evolved to mitigate limitations, WebAssembly addresses some issues directly.

Issues Include:

• JavaScript is distributed in text format and WebAssembly is a binary.
• JavaScript is not strongly typed, so optimization requires complex runtime monitoring. WebAssembly is strongly typed and can be compiled very quickly to the native machine code.
• The WebAssembly binary format is designed to support parallel decoding across multiple threads and streamed instantiation.

WebAssembly’s efficiency applies to host targets beyond the web. The W3C group carefully specified “host” rather than “browser” regarding a host which loads and interoperates with WebAssembly. Modules can be hosted and executed across several environments, including cloud, Internet of Things (IoT), or blockchain.

Security

WebAssembly runs in the browser and from a security perspective, browsers are rife with vulnerabilities. WebAssembly incorporates a few features which help to mitigate opportunities for exploits.

The WebAssembly runtime adheres to the same security policies as its host environment. Within the web, WebAssembly conforms to the same-origin policy; a page cannot load and execute a malicious WebAssembly module from a different origin.

WebAssembly modules run within a sandbox and are therefore isolated from the host environment, so all functionality must be imported. This sandbox separates the execution environments of different modules. In addition, the sandbox validates code to minimize data corruption.

WebAssembly can access linear memory and functions but requires a host for import and export. The lack of I/O significantly reduces the attack surface as the WebAssembly instance is only able to access what is available through the interfaces it is linked with.

Independency

Aspects of WebAssembly, such as its low-level binary format, lend towards independencies contributing to the language’s portability and performance.

Hardware Independent:
WebAssembly compiles on all modern systems, including desktop and mobile.

Language Independent:
WebAssembly acts as a compilation target for various languages and continues to innovate by implementing requests. WebAssembly does not promote or favor any language. Coding language communities generate additional tools for utilizing WebAssembly.

Platform Independent:
WebAssembly’s host can be browser or non-browser. WebAssembly can be embedded in browsers, run as a virtual machine, and more.

WebAssembly as a non-browser runtime

Initially, WebAssembly targeted specific browser-based use cases, such as migrating performance-intensive applications into the browser. However, WebAssembly retains a platform-agnostic host environment. WebAssembly has been adopted as a non-browser runtime due to a few features:

Sandbox Environment:
WebAssembly modules provide a layer of security because modules execute within a sandbox environment. The environment increases safety for cloud computing where executing processes share the same underlying physical resources.

Vendor-neutral:
WebAssembly is flexible and untied to a particular vendor. This versatility allows for use cases to expand and meet various needs.

Runtime:
Runtime features, such as streaming compilation and simple validation rules, contribute to fast start times and near-native performance.

Memory:
WebAssembly does not have a specific approach to memory management (e.g., garbage collection) or its own system-level APIs. As a result, the WebAssembly runtime is simple and lightweight.

Bytecode Alliance

WebAssembly’s rapid adoption spurred innovation and investment from various organizations. Many projects sought to extend similar capabilities and solutions. In response, the founding organizations Mozilla, Red Hat, Intel, and Fastly formed the Bytecode Alliance to foster collaboration and promote innovation.

The Bytecode Alliance’s 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.”

The Bytecode Alliance initiated a sub-project called the WebAssembly System Interface (WASI). WASI is an API that allows WebAssembly access to system features such as files, filesystems, Berkeley sockets, clocks, and random numbers. WASI acts as a system-level interface for WebAssembly, so incorporating a runtime into a host environment and building a platform is easier.

While WASI runs in the browser, WASI is not browser-dependent and therefore does not rely on Web APIs or Javascript compatibility. With WASI, WebAssembly modules can run outside of the browser. Wasmtime, another Bytecode Alliance project, is a WebAssembly runtime that can be used as a host for non-browser use cases.

WASI maintains WebAssembly’s security advantages by extending WebAssembly’s sandboxed environment to include I/O. The API isolates modules and provides each module with permissions to particular parts of the system.

WASI use cases include cross-platform applications, code reuse across platforms, and a single runtime for applications. The Bytecode Alliance continues to contribute and accept projects with several roadmap goals for WASI addressed in online documentation on the Bytecode Alliance website.