WebAssembly

WebAssembly (Wasm) defines a portable binary code format and a corresponding text format for executable programs and software interfaces for facilitating communication between such programs and their host environment. The main goal of WebAssembly is to facilitate high-performance applications on web pages, but it is also designed to be usable in non-web environments. It is an open standard intended to support any language on any operating system, and in practice many of the most popular languages already have at least some level of support. Announced in and first released in , WebAssembly became a World Wide Web Consortium (W3C) recommendation on 5 December 2019 and it received the Programming Languages Software Award from the Association for Computing Machinery (ACM) SIGPLAN in 2021. The W3C maintains the standard with contributions from Mozilla, Microsoft, Google, Apple, Fastly, Intel, and Red Hat.

WebAssembly (Wasm) defines a portable binary code format and a corresponding text format for executable programs and software interfaces for facilitating communication between such programs and their host environment. The main goal of WebAssembly is to facilitate high-performance applications on web pages, but it is also designed to be usable in non-web environments. It is an open standard intended to support any language on any operating system, and in practice many of the most popular languages already have at least some level of support. Announced in and first released in , WebAssembly became a World Wide Web Consortium (W3C) recommendation on 5 December 2019 and it received the Programming Languages Software Award from the Association for Computing Machinery (ACM) SIGPLAN in 2021. The W3C maintains the standard with contributions from Mozilla, Microsoft, Google, Apple, Fastly, Intel, and Red Hat. In March 2017, the design of the minimum viable product (MVP) was declared to be finished and the preview phase ended. In late September 2017, Safari 11 was released with support. In February 2018, the WebAssembly Working Group published three public working drafts for the Core Specification, JavaScript Interface, and Web API. The MVP was focused on low-level languages such as C and C++, with the intent to add features useful for high-level languages in a future version. Multithreading is currently a draft, but has been supported by Chrome since version 75 in June 2019, Firefox version 79, and Safari version 14.1 The WebAssembly 2.0 specification was finished in 2022 and became a W3C standard in December 2024. It adds many single instruction, multiple data (SIMD) related instructions and a new v128 datatype, with the ability for functions to return multiple values, mass memory initialize/copy instructions, and reference types, which are opaque pointers to objects outside of the linear memory. WebAssembly 3.0 was released in September 2025¹. New features include a 64-bit address space, multiple address spaces, exception handling, and garbage collected struct and array types. Support for garbage collection enables more efficient compiling for high-level languages, but WasmGC from WebAssembly 3.0 lacks the abilities needed by .NET runtime. === Web browsers === In November 2017, Mozilla declared support "in all major browsers", after WebAssembly was enabled by default in Edge [Legacy] 16. This support also includes mobile web browsers for iOS and Android. 99% of tracked web browsers support WebAssembly (version 1.0), more than for its predecessor asm.js. For some extensions, from the 2.0 draft standard, support may be lower, but still more than 90% of web browsers may already support, e.g. the reference types extension. == Performance== Early on, the execution speed of a Wasm program was benchmarked to be around 91% of (or about 10% slower than) a comparable native program, not including load/instantiation time; however, various later benchmarks indicate a wide range of performance characteristics, from 33% to 200% of the execution speed of native code, depending on the task. In 2019, a group of researchers from the University of Massachusetts Amherst presented a comprehensive analysis of WebAssembly's performance compared to native code. This study used the SPEC CPU suite of benchmarks and a system called "Browsix-Wasm" to run unmodified Unix applications in the browser, thereby allowing for a test of real-world applications, finding a significant performance gap between Wasm execution and native execution; in particular, Wasm programs showed an average slowdown of 45% in Firefox and 55% in Chrome across the real-world benchmarks; peak slowdowns resulted in a Wasm program taking 2.08 times as long to run in Firefox and 2.5 times as long to run in Chrome. The paper identified several reasons for this performance difference, including missing optimizations, code generation issues in WebAssembly compilers, and inherent limits of the WebAssembly platform. A 2021 study suggested that WebAssembly is much faster than JavaScript in certain cases, such as running a complex function on a small file (e.g., processing a graphics file); however, at the time, the JavaScript interpreter had some optimizations available that the WebAssembly implementations did not have (e.g., Just-in-time compilation). In 2022, it was determined by researchers that a Wasm program runs at about 120% of (or 20% faster than) the speed of a comparable JavaScript program. Those findings align with the experience of a startup company named "Zaplib", whose founders summarized in a blog that it was shutting down due to lack of performance in WebAssembly. Their goal had been to significantly increase the performance of existing web apps by incrementally porting them to Rust/Wasm; however, porting a customer's simulator from JavaScript yielded only a 5% improvement in performance. Similarly, regarding Figma, they stated the following: [Upon] closer inspection it seems that [Figma's] use of Wasm is more due to historical accidents—wanting to build in C++ to hedge for their native app—than for critical performance needs. Figma files are processed in C++/Wasm, and this is likely a huge speedup, but most of Figma's performance magic is due to their WebGL renderer. In 2023, a study of Wasm's performance for cryptographic tasks indicated 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 2 tests where the native code benefited from special instructions implemented directly in the CPU of the target platform; for those particular tests, the Wasm programs were "80 times slower than native code". Benchmarking has revealed several other pain-points for WebAssembly, such as poor performance because of no direct access to the DOM, a problem which is being addressed. == WASI == WebAssembly System Interface (WASI) is a simple interface (application binary interface (ABI) and application programming interface (API)) designed by Mozilla, which is intended to be portable to any platform. It provides features similar to the Portable Operating System Interface (POSIX), such as file input/output (I/O) constrained by capability-based security. There are additional proposed ABI/APIs. WASI is influenced by CloudABI and Capsicum. , a co-founder of Docker, wrote 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." WASI 0.1 provides a few POSIX-like APIs such as file I/O, reading environment variables, and random-number generation, but has very little support for networking. WASI 0.2 is redesigned based on the WebAssembly Component Model. WASI 0.3 will add support for async functions; the host translates between blocking and async function calls, so an exported function that blocks may be called as an asynchronous function, and vice-versa. Starting in 0.2, WASI is defined in terms of the component model. Interfaces in the component model are specified in an IDL called WIT (WebAssembly Interface Types). While core wasm only supports integer and floating-point numbers, interfaces in WIT can express types such as strings, lists, and user-defined record and variant types, and are language-agnostic. Components cannot access each other's memory, and so interact only via imported and exported functions. The component model is designed around composition: two components can be composed into a single component when the exports of one component match another's imports, allowing any interface to be virtualized. Interfaces in WIT are grouped together into a "world". WASI 0.2 defines a CLI world similar to the POSIX-like API of WASI 0.1, and an HTTP proxy world for web servers. WASI 0.2 (also known as Preview 2) was released on January 25, 2024, introducing the Component Model and WIT (WebAssembly Interface Types), which enable cross-language module composition and networking support via TCP/UDP sockets. The component model is not currently supported by browsers. == Specification == (module (type $t0 (func (param i64) (result i64))) (func $f0 (type $t0) (param $p0 i64) (result i64) (if $I0 (result i64) ;; $I0 is an unused label name (i64.eqz (local.get $p0)) ;; the name $p0 is the same as 0 here (then (i64.const 1)) (else (i64.mul (local.get $p0) (call $f0 ;; the name $f0 is the same as 0 here (i64.sub (local.get $p0) (i64.const 1)))))))) A module is implicitly generated by the compiler. The function is referenced by an entry of the type table in the binary, hence a type section and the emitted by the decompiler. The compiler and decompiler can be accessed online.

Text derived from https://en.wikipedia.org/w/index.php?oldid=1374012305 under CC BY-SA 4.0; modifications have been made.