![]() | |
Paradigm | structured ; stack machine [1] |
---|---|
Designed by | W3C |
Developer | |
First appeared | March 2017 |
OS | Platform independent |
License | Apache License 2.0 |
Filename extensions |
|
Website | webassembly |
Influenced by | |
WebAssembly (Wasm) defines a portable binary-code format and a corresponding text format for executable programs [2] as well as software interfaces for facilitating interactions between such programs and their host environment. [3] [4] [5] [6]
The main goal of WebAssembly is to enable high-performance applications on web pages, "but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well." [7] It is an open standard [8] [9] and aims to support any language on any operating system, [10] and in practice all of the most popular languages already have at least some level of support.
Announced in 2015 and first released in March 2017 , WebAssembly became a World Wide Web Consortium recommendation on 5 December 2019 [11] [12] [13] and it received the Programming Languages Software Award from ACM SIGPLAN in 2021. [14] The World Wide Web Consortium (W3C) maintains the standard with contributions from Mozilla, Microsoft, Google, Apple, Fastly, Intel, and Red Hat. [15] [16]
WebAssembly is named to evoke the concept of assembly language, a term which dates to the 1950s. The name suggests bringing assembly-like programming to the Web, where it will be executed client-side — by the website-user's computer via the user's web browser. To accomplish this, WebAssembly must be much more hardware-independent than a true assembly language.
WebAssembly was first announced in 2015, [17] and the first demonstration was executing Unity's Angry Bots in Firefox, [18] Google Chrome, [19] and Microsoft Edge. [20] The precursor technologies were asm.js from Mozilla and Google Native Client, [21] [22] and the initial implementation was based on the feature set of asm.js. [23] The asm.js technology already provides near-native code execution speeds [24] [25] and can be considered a viable alternative for browsers that do not support WebAssembly or have it disabled for security reasons.
In March 2017, the design of the minimum viable product (MVP) was declared to be finished and the preview phase ended. [26] 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. [27] [28] [29] [30]
In June 2019, Chrome 75 was released with WebAssembly threads enabled by default. [31]
Since April 2022, [update] WebAssembly 2.0 is in draft status, [32] [33] which adds many SIMD-related instructions and a new v128 datatype, the ability for functions to return multiple values, and mass memory initialize/copy.
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. [34] [35] 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 . [9] [10] WebAssembly runtime environments are embedded in application servers to host "server-side" WebAssembly applications and in other applications to support plug-in-based software extension architectures, e.g., "WebAssembly for Proxies" (proxy-wasm) which specifies a WebAssembly-based ABI for extending proxy servers. [36] [37]
In November 2017, Mozilla declared support "in all major browsers", [38] after WebAssembly was enabled by default in Edge 16. [39] The support includes mobile web browsers for iOS and Android. As of March 2024, [update] 99% of tracked web browsers support WebAssembly (version 1.0), [40] which is more than for its predecessor asm.js, that is not supported by e.g. Safari web browser. 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. for reference types extension. [41]
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, [10] Wasmtime [42] or WAMR, [16] wasm3, WAVM, and many others. [43]
Because WebAssembly executables are precompiled, it is possible to use a variety of programming languages to make them. [44] 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. [45]
Emscripten compiles C and C++ to Wasm [26] using the Binaryen and LLVM as backend. [46] The Emscripten SDK can compile any LLVM-supported languages (such as C, C++ or Rust, among others) source code into a binary file which runs in the same sandbox as JavaScript code. [note 1] Emscripten provides bindings for several commonly used environment interfaces like WebGL.
As of version 8, a standalone Clang can compile C and C++ to Wasm. [51] Its initial aim was to support compilation from C and C++, [52] though support for other source languages such as Rust, .NET languages [53] [54] [45] and AssemblyScript [55] (TypeScript-like) is also emerging.
After the MVP release, WebAssembly added support for multithreading and garbage collection [56] [57] which enabled compilation for garbage-collected programming languages like C# (supported via Blazor), F# (supported via Bolero [58] with help of Blazor), Python, and even JavaScript where the browser's just-in-time compilation speed is considered too slow.
A number of other languages have some support including Python, [59] Julia, [60] [61] [62] , Ruby [63] and Ring. [64] [65]
A number of systems can compile Java and other bytecode languages to JavaScript and WebAssembly. These include CheerpJ, [66] JWebAssembly [67] and TeaVM. [68] These all take Java byte code .class files as input allowing other JVM languages like Groovy, and Scala to be used as well. Kotlin supports WebAssembly directly. [69] [70]
Web browsers do not allow WebAssembly code to directly access the Document Object Model. Wasm code must defer to JavaScript for this. [note 2]
In an October 2023 survey of developers, less than half of the 303 participants were satisfied with the state of WebAssembly. A large majority cited the need for improvement in four areas: WASI, debugging support, integration with JavaScript and browser APIs, and build tooling. [73]
For memory-intensive allocations in WebAssembly, 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." [74]
All major browsers allow WebAssembly if Content-Security-Policy is not specified, or if "unsafe-eval" is used, but otherwise they behave differently. [75] Chrome requires "unsafe-eval", [76] [77] though a worker thread can be a workaround. [77]
In 2022, the startup company named Zaplib summarized in a blog why they were shutting down. [78] 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 only yielded a 5% improvement. [78] Regarding Figma, they stated: "upon closer inspection it seems that their 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." [78]
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. [79] [80] [81] However, in order to explore these future language extensions, Google Chrome added experimental support for the WebAssembly thread proposal in October 2018. [82]
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". [83] The speed and concealability of WebAssembly have led to its use in hidden crypto mining on the website visitor's device. [83] [84] [79] 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." [79] 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. [85] [86] 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. [87]
The ability to effectively obfuscate large amounts of code can also be used to bypass ad blocking and privacy tools that prevent web tracking like Privacy Badger.[ citation needed ]
As WebAssembly supports only structured control flow, it is amenable toward security verification techniques including symbolic execution. [88] Current efforts in this direction include the Manticore symbolic execution engine. [89]
WebAssembly System Interface (WASI) is a simple interface (ABI and API) designed by Mozilla intended to be portable to any platform. [90] It provides POSIX-like features like file I/O constrained by capability-based security. [91] [92] There are also a few other proposed ABI/APIs. [93] [94]
WASI is influenced by CloudABI and Capsicum.
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." [95] 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". [95]
The general standard provides core specifications for JavaScript API and details on embedding. [5]
Wasm code (binary code, i.e. bytecode) is intended to be run on a portable virtual stack machine (VM). [96] The VM is designed to be faster to parse and execute than JavaScript and to have a compact code representation. [52] Any external functionality (like syscalls) that may be expected by Wasm binary code is not stipulated by the standard. It rather provides a way to deliver interfacing via modules by the host environment that the VM implementation runs in. [97] [9]
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. [98] Such module may provide a start function that is executed upon instantiation of a wasm binary.
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). [99] The list of instructions includes standard memory load/store instructions, numeric, parametric, control of flow instruction types and Wasm-specific variable instructions. [100]
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). [101] [102] Those instructions, the "finalized opcodes" [103] are enabled by default across Google's V8 (in Google Chrome), the SpiderMonkey engine in Mozilla Firefox, and the JavaScriptCore engine in Apple's Safari [104] 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. [105]
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, [106] 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.
In March 2017, the WebAssembly Community Group reached consensus on the initial (MVP) binary format, JavaScript API, and reference interpreter. [107] It defines a WebAssembly binary format (.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.
C source code | WebAssembly .wat text format | WebAssembly .wasm binary format |
---|---|---|
intfactorial(intn){if(n==0)return1;elsereturnn*factorial(n-1);} | (func(parami64)(resulti64)local.get0i64.eqzif(resulti64)i64.const1elselocal.get0local.get0i64.const1i64.subcall0i64.mulend) | 00 61 73 6D 01 00 00 00 01 06 01 60 01 7E 01 7E 03 02 01 00 0A 17 01 15 00 20 00 50 04 7E 42 01 05 20 00 20 00 42 01 7D 10 00 7E 0B 0B |
All integer constants are encoded using a space-efficient, variable-length LEB128 encoding. [108]
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. [109] Through wasm2wat
, the code above decompiles to:
(module(type$t0(func(parami64)(resulti64)))(func$f0(type$t0)(param$p0i64)(resulti64)(if$I0(resulti64);; $I0 is an unused label name(i64.eqz(local.get$p0));; the name $p0 is the same as 0 here(then(i64.const1))(else(i64.mul(local.get$p0)(call$f0;; the name $f0 is the same as 0 here(i64.sub(local.get$p0)(i64.const1))))))))
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. [110] The compiler and decompiler can be accessed online. [111]
.wasm
files which then may be executed in a web browser. [47] [48] [49] Even though Emscripten can consume various languages when using Clang, some problems may arise. [50] Bytecode is a form of instruction set designed for efficient execution by a software interpreter. Unlike human-readable source code, bytecodes are compact numeric codes, constants, and references that encode the result of compiler parsing and performing semantic analysis of things like type, scope, and nesting depths of program objects.
A browser extension is a software module for customizing a web browser. Browsers typically allow users to install a variety of extensions, including user interface modifications, cookie management, ad blocking, and the custom scripting and styling of web pages.
V8 is a JavaScript and WebAssembly engine developed by Google for its Chrome browser. V8 is free and open-source software that is part of the Chromium project and also used separately in non-browser contexts, notably the Node.js runtime system.
Google Native Client (NaCl) is a discontinued sandboxing technology for running either a subset of Intel x86, ARM, or MIPS native code, or a portable executable, in a sandbox. It allows safely running native code from a web browser, independent of the user operating system, allowing web apps to run at near-native speeds, which aligns with Google's plans for ChromeOS. It may also be used for securing browser plugins, and parts of other applications or full applications such as ZeroVM.
Google Closure Tools is a set of tools to help developers build rich web applications with JavaScript. It was developed by Google for use in their web applications such as Gmail, Google Docs and Google Maps. As of 2023, the project had over 230K LOCs not counting the embedded Mozilla Rhino compiler.
Node.js is a cross-platform, open-source JavaScript runtime environment that can run on Windows, Linux, Unix, macOS, and more. Node.js runs on the V8 JavaScript engine, and executes JavaScript code outside a web browser.
CommonJS is a project to standardize the module ecosystem for JavaScript outside of web browsers.
Dart is a programming language designed by Lars Bak and Kasper Lund and developed by Google. It can be used to develop web and mobile apps as well as server and desktop applications.
Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. It is a Candidate Recommendation of the W3C working group on Web Application Security, widely supported by modern web browsers. CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website—covered types are JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features.
HTML audio is a subject of the HTML specification, incorporating audio input, playback, and synthesis, all in the browser.
Emscripten is an LLVM/Clang-based compiler that compiles C and C++ source code to WebAssembly, primarily for execution in web browsers.
asm.js is a subset of JavaScript designed to allow computer software written in languages such as C to be run as web applications while maintaining performance characteristics considerably better than standard JavaScript, which is the typical language used for such applications.
GraalVM is a Java Development Kit (JDK) written in Java. The open-source distribution of GraalVM is based on OpenJDK, and the enterprise distribution is based on Oracle JDK. As well as just-in-time (JIT) compilation, GraalVM can compile a Java application ahead of time. This allows for faster initialization, greater runtime performance, and decreased resource consumption, but the resulting executable can only run on the platform it was compiled for.
Media Source Extensions (MSE) is a W3C specification that allows JavaScript to send byte streams to media codecs within web browsers that support HTML video and audio. Among other possible uses, this allows the implementation of client-side prefetching and buffering code for streaming media entirely in JavaScript. It is compatible with, but should not be confused with, the Encrypted Media Extensions (EME) specification, and neither requires the use of the other, although many EME implementations are only capable of decrypting media data provided via MSE.
A headless browser is a web browser without a graphical user interface.
WebXR Device API is a Web application programming interface (API) that describes support for accessing augmented reality and virtual reality devices, such as the HTC Vive, Oculus Rift, Oculus Quest, Google Cardboard, HoloLens, Apple Vision Pro, Magic Leap or Open Source Virtual Reality (OSVR), in a web browser. The WebXR Device API and related APIs are standards defined by W3C groups, the Immersive Web Community Group and Immersive Web Working Group. While the Community Group works on the proposals in the incubation period, the Working Group defines the final web specifications to be implemented by the browsers.
WebGPU is a JavaScript API provided by a web browser that enables webpage scripts to efficiently utilize a device's graphics processing unit (GPU). This is achieved with the underlying Vulkan, Metal, or Direct3D 12 system APIs. On relevant devices, WebGPU is intended to supersede the older WebGL standard.
Deno is a runtime for JavaScript, TypeScript, and WebAssembly that is based on the V8 JavaScript engine and the Rust programming language. Deno was co-created by Ryan Dahl, who also created Node.js.
AssemblyScript is a TypeScript-based programming language that is optimized for, and statically compiled to, WebAssembly. Resembling ECMAScript and JavaScript, but with static types, the language is developed by the AssemblyScript Project with contributions from the AssemblyScript community.
WebAssembly code can be considered a structured stack machine; a machine where most computations use a stack of values, but control flow is expressed in structured constructs such as blocks, ifs, and loops. In practice, implementations need not maintain an actual value stack, nor actual data structures for control; they need only behave as if they did so.
WebAssembly is an open standard...
WebAssembly is a ... code format
WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure.
... this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.
Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.
While the Web is the primary motivation for WebAssembly, nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future.
Compile everything to WebAssembly. Run it on any OS or embed it into other languages.
Even discarding the one score where asm.js did better, it executes at around 70% of the speed of native C++ code.
{{cite book}}
: CS1 maint: multiple names: authors list (link)The goal of this crate is to provide Rust bindings to the Web APIs and to allow a high degree of interoperability between Rust and JavaScript.
Raw API bindings for Web APIs. This is a procedurally generated crate from browser WebIDL which provides a binding to all APIs that browser provide on the web.
This article incorporates text from a free content work. Licensed under Apache License 2.0( license statement/permission ). Text taken from Text Format , jfbastien; rossberg-chromium; kripken; titzer; s3ththompson; sunfishcode; lukewagner; flagxor; enricobacis; c3d; binji; andrewosh, GitHub. WebAssembly/design.