WebAssembly (sometimes abbreviated Wasm) is an open standard that defines a portable binary-code format for executable programs, and a corresponding textual assembly language, as well as interfaces for facilitating interactions between such programs and their host environment. The main goal of WebAssembly is to enable high-performance applications on web pages, but the format is designed to be executed and integrated in other environments as well, including standalone ones.
WebAssembly can support (at least in theory) any language (e.g. compiled or interpreted) on any operating system (with help of appropriate tools), and in practice all of the most popular languages already have at least some level of support.
WebAssembly implementations usually use either ahead-of-time (AOT) or just-in-time (JIT) compilation, but may also use an interpreter. While the first implementations have landed in web browsers, there are also non-browser implementations for general-purpose use, including Wasmer, Wasmtime or WAMR, wasm3, WAVM, and many others. The WebAssembly website has .
WebAssembly was first announced in 2015, and the first demonstration was executing Unity's Angry Bots in Firefox, Google Chrome, and Microsoft Edge. The precursor technologies were asm.js from Mozilla and Google Native Client, and the initial implementation was based on the feature set of asm.js. The asm.js technology already provides near-native code execution speeds and can be considered a viable alternative for browsers that don't support WebAssembly or have it disabled for security reasons.
While WebAssembly was initially designed to enable near-native code execution speed in the web browser, it has been considered valuable outside of such, in more generalized contexts. Since WebAssembly's runtime environments (RE) are low level virtual stack machines (akin to JVM or Flash VM) that can be embedded into host applications, some of them have found a way to standalone runtime environments like Wasmtime and Wasmer.
Because WebAssembly executables are precompiled, it is possible to use a variety of programming languages to make them. This is achieved either through direct compilation to Wasm, or through implementation of the corresponding virtual machines in Wasm. There have been around 40 programming languages reported to support Wasm as a compilation target.
WebAssembly is supported on desktops, and mobile, but on the latter, in practice (for non-small memory allocations, such as with Unity game engine) there are "grave limitations that make many applications infeasible to be reliably deployed on mobile browsers [..] Currently allocating more than ~300MB of memory is not reliable on Chrome on Android without resorting to Chrome-specific workarounds, nor in Safari on iOS."
All major web browsers allow WebAssembly if Content-Security-Policy is not specified, or if "unsafe-eval" is used, but otherwise the major web browsers behave differently. In practice WebAssembly can't be used on Chrome without "unsafe-eval", while a worker thread workaround is available.
In June 2018, a security researcher presented the possibility of using WebAssembly to circumvent browser mitigations for Spectre and Meltdown security vulnerabilities once support for threads with shared memory is added. Due to this concern, WebAssembly developers put the feature on hold. However, in order to explore these future language extensions, Google Chrome added experimental support for the WebAssembly thread proposal in October 2018.
WebAssembly has been criticized for allowing greater ease of hiding the evidence for malware writers, scammers and phishing attackers; WebAssembly is present on the user's machine only in its compiled form, which "[makes malware] detection difficult". The speed and concealability of WebAssembly have led to its use in hidden crypto mining on the website visitor's device. Coinhive, a now defunct service facilitating cryptocurrency mining in website visitors' browsers, claims their "miner uses WebAssembly and runs with about 65% of the performance of a native Miner." A June 2019 study from the Technische Universität Braunschweig analyzed the usage of WebAssembly in the Alexa top 1 million websites and found the prevalent use was for malicious crypto mining, and that malware accounted for more than half of the WebAssembly-using websites studied. An April 2021 study from Universität Stuttgart found that since then crypto mining has been marginalized, falling to below 1% of all WebAssembly modules gathered from a wide range of sources, also including the Alexa top 1 million websites.
As WebAssembly supports only structured control flow, it is amenable toward security verification techniques including symbolic execution. Current efforts in this direction include the Manticore symbolic execution engine.
WebAssembly System Interface (WASI) is a simple interface (ABI and API) designed by Mozilla intended to be portable to any platform. It provides POSIX-like features like file I/O constrained by capability-based security. There are also a few other proposed ABI/APIs.
Solomon Hykes, 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." Wasmer, out in version 1.0, provides "software containerization, we create universal binaries that work anywhere without modification, including operating systems like Linux, macOS, Windows, and web browsers. Wasm automatically sandboxes applications by default for secure execution".
A Wasm program is designed to be a separate module containing collections of various Wasm-defined values and program type definitions. These are expressed in either binary or textual format (see below) that both have a common structure.
The core standard for the binary format of a Wasm program defines an instruction set architecture (ISA) consisting of specific binary encodings of types of operations which are executed by the VM (without specifying how exactly they must be executed). The list of instructions includes standard memory load/store instructions, numeric, parametric, control of flow instruction types and Wasm-specific variable instructions.
The number of opcodes used in the original standard (MVP) was a bit fewer than 200 of the 256 possible opcodes. Subsequent versions of WebAssembly pushed the number of opcodes a bit over 200. The WebAssembly SIMD proposal (for parallel processing) introduces an alternate opcode prefix (0xfd) for 128-bit SIMD. The concatenation of the SIMD prefix, plus an opcode that is valid after the SIMD prefix, forms a SIMD opcode. The SIMD opcodes bring an additional 236 instructions for the "minimum viable product" (MVP) SIMD capability (for a total of around 436 instructions). Those instructions, the "finalized opcodes" are implemented in Google's V8 (in Google Chrome) and in the corresponding engine in Mozilla Firefox (but not enabled in stable versions of the web browsers), and there are also some additional proposal for instructions for later "post SIMD MVP", and there's also a separate "relaxed-simd" proposal on the table.
These SIMD opcodes are also portable and translate to native instruction sets like x64 and ARM. In contrast, neither Java's JVM (nor CIL) support SIMD, at their opcode level, i.e. in the standard; both do have some parallel APIs which provide SIMD speedup. There is an extension for Java adding intrinsics for x64 SIMD, that isn't portable, i.e. not usable on ARM or smartphones. Smartphones can support SIMD by calling assembly code with SIMD, and C# has similar support.
.wasm), which is not designed to be used by humans, as well as a human-readable WebAssembly text format (
.wat) that resembles a cross between S-expressions and traditional assembly languages.
The table below shows an example of a factorial function written in C and its corresponding WebAssembly code after compilation, shown both in .wat text format (a human-readable textual representation of WebAssembly) and in .wasm binary format (the raw bytecode, expressed below in hexadecimal), that is executed by a Web browser or run-time environment that supports WebAssembly.
The WebAssembly text format is more canonically written in a folded format using S-expressions. For instructions and expressions, this format is purely syntactic sugar and has no behavioral differences with the linear format. Through
wasm2wat, the code above decompiles to:
Note that a module is implicitly generated by the compiler. The function is actually referenced by an entry of the type table in the binary, hence a type section and the
type emitted by the decompiler. The compiler and decompiler can be accessed online.
This article incorporates text from a free content work. Licensed under Apache License 2.0 . Text taken from , jfbastien; rossberg-chromium; kripken; titzer; s3ththompson; sunfishcode; lukewagner; flagxor; enricobacis; c3d; binji; andrewosh, GitHub. WebAssembly/design.