WebAssembly

[3][4][5][6] 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.

Announced in 2015 (2015) and first released in March 2017 (2017-03), 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.

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 [Legacy].

[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][note 1] In March 2017, the design of the minimum viable product (MVP) was declared to be finished and the preview phase ended.

[30] Since April 2022,[update] WebAssembly 2.0 has been in draft status,[31][32] which added many SIMD-related instructions and a new v128 datatype, with the ability for functions to return multiple values, and mass memory initialize/copy.

While WebAssembly was initially designed to permit near-native code execution speed in the web browser, it has been considered valuable outside of such, in more generalized contexts.

[35][36] In November 2017, Mozilla declared support "in all major browsers",[37] after WebAssembly was enabled by default in Edge [Legacy] 16.

[45] Emscripten compiles C and C++ to Wasm[25] using Clang as a frontend, replacing LLVM as backend and using Binaryen [Wikidata] as an optimizer.

A large majority cited the need for improvement in four areas: WASI, debugging support, integration with JavaScript and browser APIs, and build tooling.

[78][79][80] However, in order to explore these future language extensions, Google Chrome added experimental support for the WebAssembly thread proposal in October 2018.

[82] Speed and the easy ability to conceal in WebAssembly have led to its use in hidden crypto mining within the website visitor's device.

[84][85] 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.

[86] As WebAssembly supports only structured control flow, it is amenable toward security verification techniques including symbolic execution.

Performance was benchmarked early to be around 91% (i.e., 10% slower) for running code, not including load/instantiation time[88] or more recently between 100% and 33% of native rates,[89] and 120% of JavaScript (i.e. 20% faster).

[106][107] Those instructions, the "finalized opcodes"[108] 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[109] 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.

There is an extension for Java adding intrinsics for x64 SIMD,[111] that isn't portable, i.e. not usable on ARM or smartphones.

In March 2017, the WebAssembly Community Group reached consensus on the initial (MVP) binary format, JavaScript API, and reference interpreter.