WebAssembly

Assembly language and bytecode for web browsers

WebAssembly (Paradigm structured ; stack machine [1] Designed by W3C Developer

• W3C
• Mozilla
• Microsoft
• Google
• Apple

First appeared March 2017; 8 years ago (2017-03) OS Platform independent License Apache License 2.0 [Filename extensions]

• .wat (text format)
• .wasm (binary format)

Website webassembly.org Influenced by

• asm.js
• PNaCl
• Lisp

WebAssembly (Wasm) defines a portable binary-code format and a corresponding text format for executable programs [2] as well as software interfaces for facilitating communication between such programs and their host environment. [3] [4] [5] [6]

The primary objective of WebAssembly is to enable high-performance applications to run within web pages . However, its design also extends its utility to non-web environments. [7] It is an open standard [8] [9] intended to accommodate any programming language on any operating system, [10] and in practice, a significant number of the most popular languages already boast some level of support.

Announced in 2015 (2015) and first released in March 2017 (2017-03), WebAssembly achieved the status of a World Wide Web Consortium (W3C) Recommendation on December 5, 2019, [11] [12] [13] and was honored with the Programming Languages Software Award from ACM SIGPLAN in 2021. [14] The W3C spearheads the maintenance of the standard, benefiting from contributions from Mozilla , Microsoft , Google , Apple , Fastly , Intel , and Red Hat . [15] [16]

History

The name “WebAssembly” was conceived to evoke the idea of bringing assembly language programming capabilities to the World Wide Web , where it would execute client-side via the user’s web browser . To achieve this, WebAssembly needed to be significantly more hardware-independent than a traditional assembly language.

WebAssembly was initially unveiled in 2015, [17] with the first public demonstration showcasing the execution of Unity ’s Angry Bots game within Firefox , [9] Google Chrome , [19] and Microsoft Edge [Legacy] . [20] The foundational technologies that paved the way for WebAssembly were asm.js from Mozilla and Google Native Client , [21] [22] and the initial implementation drew heavily from the feature set of asm.js. [23] [note 1]

By March 2017, the design for the minimum viable product (MVP) was finalized, marking the conclusion of the preview phase. [25] In late September 2017, Safari 11 was released, incorporating support for WebAssembly. Subsequently, in February 2018, the WebAssembly Working Group published three public working drafts outlining the Core Specification, JavaScript Interface, and Web API. [26] [27] [28] [29]

In June 2019, Chrome 75 was rolled out with WebAssembly threads enabled by default, a significant step towards enabling more complex parallel processing capabilities within the browser.

As of April 2022, [update] WebAssembly 2.0 has been in draft status. [31] [32] This iteration introduces a plethora of new features, including numerous SIMD -related instructions and a novel v128 data type. It also enhances functionality by enabling functions to return multiple values and introduces efficient mass memory initialization and copying operations.

Implementations

While WebAssembly was initially conceptualized for near-native code execution speeds within web browsers, its inherent advantages have proven valuable in broader, more generalized contexts beyond the web. [33] [34] A WebAssembly runtime environment functions as a low-level virtual stack machine , analogous to the JVM or Flash VM . This allows it to be embedded into virtually any host application. Consequently, standalone WebAssembly runtime environments have emerged, such as Wasmtime [Wikidata] and Wasmer [Wikidata], among others. [9] [10] These runtime environments are increasingly integrated into application servers to host “server-side” WebAssembly applications. They also find application in other domains to support plug-in -based software extension architectures. A notable example is “WebAssembly for Proxies” (Proxy-Wasm), which defines a WebAssembly-based ABI specifically for extending proxy servers . [35] [36]

Web browsers

By November 2017, Mozilla announced WebAssembly support was available “in all major browsers,” [37] following its enablement by default in Edge [Legacy] 16. [38] This comprehensive support extends to mobile web browsers on both iOS and Android platforms. As of March 2024, [update] an impressive 99% of tracked web browsers offer support for WebAssembly version 1.0, [39] surpassing the adoption rate of its predecessor, [asm.js]. [40] While support for certain extensions, such as those introduced in the 2.0 draft standard, might be slightly lower, it remains robust, with over 90% of web browsers reportedly supporting features like the reference types extension. [41]

Compilers

WebAssembly implementations typically employ either ahead-of-time (AOT) or just-in-time (JIT) compilation strategies. Some may also utilize an interpreter . Although initial implementations were primarily found within web browsers, a wide array of non-browser implementations now cater to general-purpose use cases.

Implementations and runtimes

Beyond the confines of web browsers, WebAssembly runtimes such as Wasmer, [10] Wasmtime, [42] WAMR, WAVM, wasm3, and others have gained prominence. [43] These systems are adept at executing precompiled Wasm modules and often provide supplementary APIs that facilitate the integration of WebAssembly into diverse environments.

Compiler toolchains

Given that WebAssembly executables are precompiled, a broad spectrum of programming languages can target Wasm. [44] Compilation is achieved either by generating Wasm code directly or by leveraging intermediate virtual machines that are themselves implemented in Wasm.

Notable toolchains include:

• Emscripten , which compiles C and C++ to Wasm using Clang as its frontend and Binaryen for optimization. It also supports any language compatible with LLVM. [25]
• Standalone Clang (versions 8 and later) offers direct compilation capabilities to Wasm. [45]
• LLVM-based workflows are available for languages like Rust and AssemblyScript. [46]

Language support

As of 2021, approximately 40 programming languages have integrated WebAssembly as a compilation target. [46] Prominent examples include:

• C and C++: Achieved through Emscripten or standalone Clang. [25]
• Rust: Supported via rustc with a Wasm target. [47] [46]
• AssemblyScript: A language with a syntax similar to TypeScript, which compiles directly to Wasm. [48]
• Go: Native WebAssembly support was introduced in Go version 1.11. [49]
• .NET languages: C# (via Blazor ) and F# (via Bolero and Blazor). [50] [51] [52]
• Python: Facilitated through implementations like Pyodide. [53]
• Java and JVM languages: Supported via CheerpJ, [54] JWebAssembly, [55] and TeaVM. [56]
• Kotlin: Offers direct Wasm compilation support. [57] [58]
• Haskell: Supported through the GHC backend. [59]
• Julia: Community-driven implementations are available. [60]
• Ruby: Supported via mruby. [61]
• Ring: Features Wasm backend support. [62]
• Dart: Supports WebAssembly as a compilation target for building Dart and Flutter applications for the web. [63]

Recent enhancements

Subsequent to the MVP phase, WebAssembly has seen significant enhancements, including the introduction of multithreading and garbage collection (WasmGC). These advancements have dramatically improved the efficiency of compiling garbage-collected languages such as C#, F#, and Python. [64] [65]

Limitations

Web browsers impose restrictions that prevent WebAssembly code from directly manipulating the Document Object Model . Wasm code must delegate such operations to JavaScript . [note 2]

A survey conducted in October 2023 revealed that less than half of the 303 participating developers expressed satisfaction with the current state of WebAssembly. A substantial majority highlighted the need for improvements in four key areas: WASI, debugging support, seamless integration with JavaScript and browser APIs, and the overall build tooling ecosystem. [68]

Regarding memory-intensive allocations within WebAssembly, significant limitations exist that render many applications infeasible for reliable deployment on mobile browsers. Specifically, allocating more than approximately 300MB of memory is unreliable on Chrome for Android without employing Chrome-specific workarounds, and similarly problematic on Safari for iOS. [69]

While all major browsers permit WebAssembly when the Content-Security-Policy is either not specified or includes the unsafe-eval directive, their behavior diverges otherwise. [70] Chrome, for instance, mandates unsafe-eval, [71] [72] although utilizing a worker thread can serve as a viable workaround. [72]

Security considerations

In June 2018, a security researcher brought to light the potential for WebAssembly to bypass browser mitigations designed for Spectre and Meltdown security vulnerabilities, particularly once support for threads with shared memory was introduced. This concern prompted WebAssembly developers to temporarily halt the feature’s implementation. [73] [74] Nevertheless, in an effort to explore these prospective language extensions, Google Chrome introduced experimental support for the WebAssembly thread proposal in October 2018. [75]

WebAssembly has faced criticism for potentially simplifying the concealment of malware , scams, and phishing attacks. The compiled nature of WebAssembly on the user’s machine makes detection more challenging. [76] The speed and inherent obfuscation capabilities of WebAssembly have led to its exploitation for clandestine crypto mining operations within users’ devices. [76] [77] CoinI’hive, a now-defunct service that facilitated cryptocurrency mining in website visitors’ browsers, claimed their miner, built with WebAssembly, achieved approximately 65% of the performance of a native miner. [citation needed] A study conducted in June 2019 by the Technische Universität Braunschweig analyzed the prevalence of WebAssembly across the top 1 million Alexa websites and concluded that malicious cryptomining constituted the predominant use case, accounting for over half of the websites employing WebAssembly in the study. [78] [79] However, a subsequent study in April 2021 by Universität Stuttgart indicated a significant shift, with cryptomining relegated to less than 1% of all WebAssembly modules gathered from diverse sources, including the Alexa top 1 million websites. [80]

Despite these concerns, WebAssembly’s adherence to structured control flow makes it amenable to security verification techniques, including symbolic execution . [81]

Performance

Early benchmarks suggested that the execution speed of a Wasm program hovered around 91% of the speed of a comparable native program (i.e., approximately 10% slower), excluding the time required for loading and instantiation. However, subsequent benchmarks have revealed a considerably wider performance spectrum, with Wasm execution speeds ranging from 33% to 200% of native code execution speed, [citation needed] depending heavily on the specific task.

In 2019, a research team from the University of Massachusetts Amherst published a thorough analysis comparing the performance of WebAssembly against native code. [82] This study employed the SPEC CPU benchmark suite and a system called “Browsix-Wasm” to execute unmodified Unix applications within the browser. This approach allowed for the evaluation of real-world applications, revealing a notable performance disparity between Wasm execution and native execution. Specifically, Wasm programs exhibited an average slowdown of 45% in Firefox and 55% in Chrome across the tested real-world benchmarks. In some instances, the slowdown reached a peak where a Wasm program took 2.08 times longer to execute in Firefox and 2.5 times longer in Chrome. The researchers attributed this performance gap to several factors, including optimization deficiencies, code generation issues in WebAssembly compilers, and inherent limitations within the WebAssembly platform itself.

A 2021 study indicated that WebAssembly significantly outperforms JavaScript in specific scenarios, such as when executing complex functions on small files (e.g., graphics file processing). [83] However, at that time, the JavaScript interpreter benefited from certain optimizations that were not yet available in WebAssembly implementations, such as Just-in-time compilation .

By 2022, research suggested that a Wasm program generally runs about 20% faster than a comparable JavaScript program. [84] These findings resonate with the experience of a startup company named “Zaplib,” whose founders documented in a blog post their decision to cease operations due to a perceived lack of performance gains with WebAssembly. [85] Their objective had been to substantially enhance the performance of existing web apps by incrementally porting them to Rust /Wasm. However, porting a customer’s simulator from JavaScript resulted in a mere 5% improvement in performance. Similarly, regarding Figma , they offered the following perspective:

Upon closer inspection, it appears that Figma’s utilization of Wasm stems more from historical decisions—a desire to build in C++ as a contingency for their native application—rather than from critical performance imperatives. While Figma files are processed in C++/Wasm, which likely provides a substantial speedup, the majority of Figma’s performance achievements are attributed to their WebGL renderer.

In 2023, a study focused on Wasm’s performance in cryptographic tasks revealed that “when using the fastest runtime, WebAssembly was only about 2.32 times slower (median) than native code with architecture-specific optimizations.” This result excluded two specific tests where the native code benefited from specialized instructions implemented directly within the CPU of the target platform. In those particular instances, the Wasm programs were found to be “80 times slower than native code.” [86]

Benchmarking has also identified several other performance bottlenecks for WebAssembly, including suboptimal performance due to the lack of direct access to the DOM, [note 3] an issue that is actively being addressed. [88]

WASI

WebAssembly System Interface (WASI) is a streamlined interface (ABI and API ) conceptualized by Mozilla . Its primary aim is platform portability, providing POSIX -like functionalities such as file I/O, all meticulously constrained by capability-based security . [89] [90] [91] Furthermore, WASI encompasses a range of additional proposed ABI/APIs. [92] [93]

WASI draws significant inspiration from CloudABI and Capsicum . [94]

Solomon Hykes [fr], a co-founder of Docker , articulated in 2019, “If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is. WebAssembly on the server is the future of computing.” [95]

Specification

Host environment

The overarching standard provides core specifications for the JavaScript API and detailed guidelines for embedding WebAssembly. [5]

Virtual machine

Wasm code, in its binary form (bytecode), is designed to execute on a portable virtual stack machine (VM). [96] This VM is engineered for faster parsing and execution compared to JavaScript, coupled with a compact code representation. [97] Any external functionalities (such as syscalls ) that the Wasm binary code might require are not explicitly defined by the standard. Instead, the standard dictates how the host environment can furnish such an interface through a “module.” [98] [9]

Wasm program

A Wasm program is structured as an independent module, comprising various collections of Wasm-defined values and program type definitions. These modules are available in either binary or textual format (detailed below) and share a common organizational structure. [99] Such a module may designate a start function, which is executed upon the instantiation of a Wasm binary.

Instruction set

The core standard governing the binary format of a Wasm program defines an instruction set architecture (ISA). Each operation executable by the VM is assigned a unique binary encoding , known as an “opcode.” However, the precise implementation details of these operations are left unspecified, granting flexibility in the VM’s construction. [100] The repertoire of instructions includes standard memory load/store operations, numeric and parametric instructions, control of flow instruction types , and Wasm-specific variable instructions. [101]

The initial standard (MVP) utilized fewer than 200 of the 256 possible opcodes. Subsequent iterations of WebAssembly have expanded this number to slightly over 200. The WebAssembly SIMD proposal, designed for parallel processing, introduces an alternative opcode prefix (0xfd) for 128-bit SIMD instructions. The combination of the SIMD prefix and a valid opcode following it forms each SIMD opcode. These SIMD instructions add an additional 236 operations to the MVP’s SIMD capabilities, bringing the total to approximately 436 instructions. [102] [103] This comprehensive set of instructions [104] is enabled by default in several key implementations: [105]

• Google’s V8 (integrated into Google Chrome)
• Mozilla Firefox’s SpiderMonkey engine
• Apple’s Safari JavaScriptCore engine

These SIMD opcodes are designed for portability and are intended to map directly onto native instruction sets such as x86-64 and ARM . In contrast, Java’s JVM [note 4] and .NET ’s CIL do not directly support SIMD instructions. However, both platforms offer APIs for parallel processing that can yield SIMD-level speedups.

Further proposals for additional instructions are in development, including a “relaxed-simd” extension. [107]

Code representation

In March 2017, the WebAssembly Community Group reached a consensus on the initial (“MVP”) binary format, the JavaScript API, and a reference interpreter. [108] This resulted in the definition of a WebAssembly binary format (.wasm), which is not intended for human readability, and a human-readable WebAssembly text format (.wat) that bears resemblance to a blend of S-expressions and conventional assembly languages.

The table below illustrates a factorial function written in C and its corresponding WebAssembly representation after compilation. It is presented in both:

• .wat text format (a human-readable textual representation of WebAssembly)
• .wasm binary format (the raw bytecode , displayed below in hexadecimal ), which is executed by Web browsers or runtime environments supporting WebAssembly.

C source code and corresponding WebAssembly

| C source code | WebAssembly • .wat text format