WebAssembly

From HandWiki

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

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.[6] It is an open standard[7][8] intended to support any language on any operating system,[9] and in practice many of the most popular languages already have at least some level of support.

Announced in 2015 (2015) and first released in March 2017 (2017-03), WebAssembly became a World Wide Web Consortium (W3C) recommendation on 5 December 2019[10][11][12] and it received the Programming Languages Software Award from ACM SIGPLAN in 2021.[13] The W3C maintains the standard with contributions from Mozilla, Microsoft, Google, Apple, Fastly, Intel, and Red Hat.[14][15]

History

The name "WebAssembly" is intended to suggest bringing assembly language programming to the World Wide 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,[16] and the first demonstration was executing Unity's Angry Bots in Firefox,[17] Google Chrome,[18] and Microsoft Edge [Legacy].[19] The precursor technologies were asm.js from Mozilla and Google Native Client,[20][21] and the initial implementation was based on the feature set of asm.js.[22][note 1]

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

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

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[30][31][32]

The WebAssembly 2.0 specification was finished in 2022 and became a W3C standard in December 2024. It adds many 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.[33]

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.[34] Support for garbage collection enables more efficient compilation for languages like C#, F#, and Python.[35][36]

Implementations

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.[37][38] A WebAssembly runtime environment is a low-level virtual stack machine, akin to JVM or Flash VM; it can be embedded into any host application, and thus there have been created standalone WebAssembly runtime environments, including Template:Wdrl and Template:Wdrl.[8][9] 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.[39][40]

Web browsers

In November 2017, Mozilla declared support "in all major browsers",[41] after WebAssembly was enabled by default in Edge [Legacy] 16.[42] This support also includes mobile web browsers for iOS and Android. As of March 2024, 99% of tracked web browsers support WebAssembly (version 1.0),[43] more than for its predecessor asm.js.[44] 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.[45]

Non-browser runtimes

Non-browser WebAssembly runtimes include Wasmer,[9] Wasmtime,[46] WAMR, WAVM, wasm3, and others.[47] These systems execute precompiled Wasm modules and often provide additional APIs for embedding WebAssembly in different environments. Use cases for wasm outside the browser include plug-in interfaces and lightweight virtualization.[48]

Compilers

WebAssembly implementations generally use either ahead-of-time (AOT) or just-in-time (JIT) compilation, though some may also use an interpreter. While the first implementations appeared in web browsers, there are now many non-browser implementations for general-purpose use.

Compiler toolchains

Because WebAssembly executables are precompiled, a variety of programming languages can target Wasm.[49] Compilation is achieved either through direct output to Wasm or via intermediate virtual machines implemented in Wasm.

Notable toolchains include:

  • Emscripten, which compiles C and C++ to Wasm using Clang as a frontend, Binaryen as an optimizer, and can also target any LLVM-supported language.[24]
  • Standalone Clang (version 8 and later), which supports direct compilation to Wasm.[50]
  • LLVM-based workflows for languages such as Rust and AssemblyScript.[51]

Language support

As of 2021, around 40 programming languages support WebAssembly as a compilation target.[51] Examples include:

  • C and C++: via Emscripten or Clang standalone.[24]
  • Rust: via rustc with Wasm target.[52][51]
  • AssemblyScript: a TypeScript-like language compiling directly to Wasm.[53]
  • Go: native WebAssembly support introduced in Go 1.11.[54]
  • .NET languages: C# (via Blazor), F# (via Bolero and Blazor).[55][56][57]
  • Python: implementations such as Pyodide.[58]
  • Java and JVM languages: via CheerpJ,[59] JWebAssembly,[60] and TeaVM.[61]
  • Kotlin: direct Wasm compilation support.[62][63]
  • Haskell: supported via GHC backend.[64]
  • Julia: community implementations.[65]
  • Ruby: supported through MRuby.[66]
  • Ring: supported with Wasm backend.[67]
  • Dart: supported WebAssembly as a compilation target when building Dart and Flutter applications for the web[68]

Limitations

Web browsers do not permit WebAssembly code to directly manipulate 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.[71]

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."[72]

All major browsers allow WebAssembly if Content-Security-Policy is not specified, or if the value unsafe-eval is used, but behave differently otherwise;[73] Chrome requires unsafe-eval,[74][75] though a worker thread can be a workaround.[75]

Security considerations

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.[76][77] However, in order to explore these future language extensions, Google Chrome added experimental support for the WebAssembly thread proposal in October 2018.[78]

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".[79] Speed and the easy ability to conceal in WebAssembly have led to its use in hidden crypto mining within the website visitor's device.[79][80] 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."[citation needed] 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.[81][82] 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.[83]

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

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.[85] 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 limitations of the WebAssembly platform itself.

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).[86]

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.[87] 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.[88] 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".[89]

Benchmarking has revealed several other pain-points for WebAssembly, such as poor performance because of no direct access to the DOM,[note 3] a problem which is being addressed.[91]

WASI

WebAssembly System Interface (WASI) is a simple interface (ABI and API) designed by Mozilla, which is intended to be portable to any platform.[92] It provides POSIX-like features like file I/O constrained by capability-based security.[93][94] There are additional proposed ABI/APIs.[95][96]

WASI is influenced by CloudABI and Capsicum.[97]

Solomon Hykes [fr; fr], 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."[98]

Specification

Host environment

The general standard provides core specifications for the JavaScript API and details on embedding.[4]

Virtual machine

Wasm code (binary code, i.e. bytecode) is intended to be run on a portable virtual stack machine (VM).[99] The VM is designed to be faster to parse and execute than JavaScript and to have compact code representation.[100] Any external functionality (like syscalls) that may be expected by Wasm binary code is not stipulated by the standard; instead, the standard specifies how the host environment can provide such an interface via a "module".[101][8]

Wasm program

A Wasm program is designed as a separate module containing collections of various Wasm-defined values and program type definitions. These are provided in either binary or textual format (see below) that have a common structure.[102] Such a module may provide a start function that is executed upon instantiation of a wasm binary.

Instruction set

The core standard for the binary format of a Wasm program defines an instruction set architecture (ISA); each operation that can be executed by the VM is assigned a specific binary encoding (an "opcode"), but the exact way in which the operation is implemented is not specified, allowing for flexibility in the construction of a VM.[103] The list of instructions includes standard memory load/store instructions, numeric, parametric, control of flow instruction types and Wasm-specific variable instructions.[104]

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 wide SIMD instructions; the concatenation of the SIMD prefix, plus an opcode that is valid after the SIMD prefix, forms each SIMD opcode. The SIMD opcodes bring an additional 236 instructions to the MVP's SIMD capability (for a total of around 436 instructions)[105][106] This set of instructions[107] are enabled by default across a number of important implementations:[108]

  1. Google's V8 (in Google Chrome)
  2. The SpiderMonkey engine in Mozilla Firefox
  3. The JavaScriptCore engine in Apple's Safari

These SIMD opcodes are both portable and intended to map directly to native instruction sets like x86-64 and ARM. In contrast, SIMD instructions are not directly supported by Java's JVM[note 4] or .NET's CIL; however, both do have some APIs for parallel processing, which provide SIMD speedups. A newer set of "relaxed SIMD" instructions allow for a limited amount of implementation-defined behavior to improve performance.[110][111]

Code representation

In March 2017, the WebAssembly Community Group reached consensus on the initial ("MVP") binary format, JavaScript API, and reference interpreter.[112] 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 binary format is straightforward and designed to allow streaming compilation, so compilation can begin before the module is finished downloading, and to allow functions to be compiled in parallel.[29]

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 and corresponding WebAssembly
C source code WebAssembly .wat text format WebAssembly .wasm binary format 
int factorial(int n) {
    if (n == 0) {
        return 1;
    } else {
        return n * factorial(n - 1);
    }
}

(func (param i64) (result i64)
  local.get 0
  i64.eqz
  if (result i64)
      i64.const 1
  else
      local.get 0
      local.get 0
      i64.const 1
      i64.sub
      call 0
      i64.mul
  end)

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

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.[114] Through wasm2wat, the code above decompiles to: 

(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 type emitted by the decompiler.[115] The compiler and decompiler can be accessed online.[116]

Memory and variables

Data in memory is stored in a large, growable array of bytes termed a linear memory. Linear memory is separate from the wasm module's call stack and code and the engine's memory. This allows running wasm code in the same process as the JavaScript virtual machine it's embedded in without violating memory safety.[29]

A module contains a list of global variables separate from linear memory, which may be mutable or immutable. Functions declare a list of local variables. A function's parameters are also local variables.

Instructions operate on a stack of values. The stack layout is fixed (branches must push and pop the same number of operands), so wasm engines can compile the stack away, producing efficient machine code operations on registers, rather than managing a stack at runtime. A stack machine architecture was chosen as it can have higher code density than a register machine.[29]

Control flow

Unlike typical assembly languages, wasm only uses structured control flow similar to high-level programming languages. The intentional lack of support for jump instructions makes it simple to validate and compile wasm code in a single pass, and makes it easier to read code disassembled into the text format.

Blocks are delimited with the block, loop, and if/else constructs. Branch instructions contain a label that identifies the depth of a block it is nested in: br 0 will branch to the block the instruction is contained in, br 1 will branch to the block that block is contained in, and so on. Branches to a block or if jump to the end of the block like a break statement, while branches to a loop jump back to the beginning of the loop, similar to a continue statement. The br_table instruction takes an input index and jumps to a target from a list of labels. A C-style switch statement can be expressed with a br_table inside a series of nested blocks.[29][117]

Compilers targeting wasm convert unstructured control flow into high-level loops using Emscripten's Relooper algorithm, originally designed to target JavaScript.[118]

Functions

Function declarations are listed in a separate section before the section containing the function bodies. Function pointers are emulated using an index into the global functions table, since the wasm code cannot access the linear memory. Functions can also be imported, providing the foreign function interface to communicate with JavaScript or other embedders.[29]

See also

Notes

  1. ↑ The asm.js file already provides near-native code execution speeds: "Even discarding the one score where asm.js did better, it executes at around 70% of the speed (i.e., slower) of native C++ code.[23] and can be considered a viable alternative for browsers that do not support WebAssembly or have it disabled for security reasons.
  2. ↑ For Rust/Wasm development, third-party libraries can provide some of the necessary JavaScript I/O.[69][70]
  3. ↑ "WebAssembly provides no access to the surrounding environment other than via the JavaScript API described in the JS API specification."[90]
  4. ↑ There is an extension for Java adding intrinsics for x86-64 SIMD instructions,[109] that isn't portable, i.e. not usable on ARM or smartphones.

References

  1. ↑ "Understanding WebAssembly text format" (in en-US). https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format. 
  2. ↑ "Introduction — WebAssembly 1.0". https://webassembly.github.io/spec/core/intro/introduction.html. "WebAssembly is an open standard..." 
  3. ↑ "Introduction — WebAssembly 1.0". https://webassembly.github.io/spec/core/intro/introduction.html. "WebAssembly is a ... code format" 
  4. ↑ 4.0 4.1 "Conventions — WebAssembly 1.0". https://webassembly.github.io/spec/core/syntax/conventions.html. "WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure." 
  5. ↑ "Introduction — WebAssembly 1.0". https://webassembly.github.io/spec/core/intro/introduction.html. "... 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." 
  6. ↑ "Introduction — WebAssembly 1.1". https://webassembly.github.io/spec/core/intro/introduction.html. "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." 
  7. ↑ Haas, Andreas; Rossberg, Andreas; Schuff, Derek L.; Titzer, Ben L.; Holman, Michael; Gohman, Dan; Wagner, Luke; Zakai, Alon et al. (14 June 2017). "Bringing the Web Up to Speed with WebAssembly". SIGPLAN Notices 52 (6): 185–200. doi:10.1145/3140587.3062363. ISSN 0362-1340. "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.". 
  8. ↑ 8.0 8.1 8.2 "Outside the web: standalone WebAssembly binaries using Emscripten · V8". https://v8.dev/blog/emscripten-standalone-wasm#running-in-wasm-runtimes. 
  9. ↑ 9.0 9.1 9.2 "Wasmer - The Universal WebAssembly Runtime". https://wasmer.io/. "Compile everything to WebAssembly. Run it on any OS or embed it into other languages." 
  10. ↑ "WebAssembly Core Specification". https://www.w3.org/TR/wasm-core-1/. 
  11. ↑ Couriol, Bruno. "WebAssembly 1.0 Becomes a W3C Recommendation and the Fourth Language to Run Natively in Browsers". https://www.infoq.com/news/2019/12/webassembly-w3c-recommendation/. 
  12. ↑ "WebAssembly Specification — WebAssembly 1.1". https://webassembly.github.io/spec/core/. 
  13. ↑ "Programming Languages Software Award". http://www.sigplan.org/Awards/Software/. 
  14. ↑ Bright, Peter (18 June 2015). "The Web is getting its bytecode: WebAssembly". Ars Technica. Condé Nast. https://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly/. 
  15. ↑ "New Bytecode Alliance Brings the Security, Ubiquity, and Interoperability of the Web to the World of Pervasive Computing" (in en). Mozilla. 12 November 2019. https://blog.mozilla.org/press/2019/11/new-bytecode-alliance-brings-the-security-ubiquity-and-interoperability-of-the-web-to-the-world-of-pervasive-computing/. 
  16. ↑ "Launch bug". 11 June 2015. https://github.com/WebAssembly/design/issues/150. 
  17. ↑ Wagner, Luke (14 March 2016). "A WebAssembly Milestone: Experimental Support in Multiple Browsers". https://hacks.mozilla.org/2016/03/a-webassembly-milestone/. 
  18. ↑ Thompson, Seth (15 March 2016). "Experimental support for WebAssembly in V8". https://v8project.blogspot.com/2016/03/experimental-support-for-webassembly.html. 
  19. ↑ Zhu, Limin (15 March 2016). "Previewing WebAssembly experiments in Microsoft Edge". https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-experiments/. 
  20. ↑ Lardinois, Frederic (17 June 2015). "Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web" (in en). TechCrunch. https://techcrunch.com/2015/06/17/google-microsoft-mozilla-and-others-team-up-to-launch-webassembly-a-new-binary-format-for-the-web/. 
  21. ↑ Avram, Abel (31 May 2017). "Google Is to Remove Support for PNaCl". https://www.infoq.com/news/2017/05/pnacl-webassembly-google. 
  22. ↑ "WebAssembly: a binary format for the web". ②ality – JavaScript and more. 18 June 2015. https://www.2ality.com/2015/06/web-assembly.html. 
  23. ↑ "Staring at the Sun: Dalvik vs. ASM.js vs. Native". August 2013. https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/. 
  24. ↑ 24.0 24.1 24.2 Krill, Paul (6 March 2017). "WebAssembly is now ready for browsers to use" (in en). InfoWorld. https://www.infoworld.com/article/3176681/. 
  25. ↑ "WebAssembly First Public Working Drafts". W3C. 15 February 2018. https://www.w3.org/blog/news/archives/6838. 
  26. ↑ "WebAssembly Core Specification". W3C. 15 February 2018. https://www.w3.org/TR/2018/WD-wasm-core-1-20180215/. 
  27. ↑ "WebAssembly JavaScript Interface". W3C. 15 February 2018. https://www.w3.org/TR/2018/WD-wasm-js-api-1-20180215/. 
  28. ↑ "WebAssembly Web API". W3C. 15 February 2018. https://www.w3.org/TR/2018/WD-wasm-web-api-1-20180215/. 
  29. ↑ 29.0 29.1 29.2 29.3 29.4 29.5 Haas, Andreas; Rossberg, Andreas; Schuff, Derek L.; Titzer, Ben L.; Holman, Michael; Gohman, Dan; Wagner, Luke; Zakai, Alon et al. (2017-06-14). "Bringing the web up to speed with WebAssembly". Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation. PLDI 2017 (New York, NY, USA: Association for Computing Machinery): 185–200. doi:10.1145/3062341.3062363. ISBN 978-1-4503-4988-8. https://doi.org/10.1145/3062341.3062363. 
  30. ↑ "WebAssembly Worker Based Threads - Chrome Platform Status". https://chromestatus.com/feature/5724132452859904. 
  31. ↑ "Feature Status - WebAssembly" (in en). https://webassembly.org/features/. 
  32. ↑ WebAssembly/threads, WebAssembly, 2026-01-03, https://github.com/WebAssembly/threads, retrieved 2026-01-05 
  33. ↑ "Wasm 2.0 Completed - WebAssembly" (in en). https://webassembly.org/news/2025-03-20-wasm-2.0/. 
  34. ↑ "Wasm 3.0 Completed - WebAssembly" (in en). https://webassembly.org/news/2025-09-17-wasm-3.0/. 
  35. ↑ "WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome". https://developer.chrome.com/blog/wasmgc. 
  36. ↑ "A new way to bring garbage collected programming languages efficiently to WebAssembly · V8". https://v8.dev/blog/wasm-gc-porting#demo-and-status. 
  37. ↑ "Non-Web Embeddings". WebAssembly. https://webassembly.org/docs/non-web/. 
  38. ↑ "Non-Web Embeddings". GitHub / WebAssembly. https://github.com/WebAssembly/design/blob/master/NonWeb.md. 
  39. ↑ Freese, Danny (2023-10-03). "Proxy-Wasm: It's WebAssembly for Proxies". https://konghq.com/blog/engineering/proxy-wasm. 
  40. ↑ "proxy-wasm/spec: WebAssembly for Proxies (ABI specification)". https://github.com/proxy-wasm/spec. 
  41. ↑ "WebAssembly support now shipping in all major browsers" (in en-US). https://blog.mozilla.org/blog/2017/11/13/webassembly-in-browsers/. 
  42. ↑ "Introducing new JavaScript optimizations, WebAssembly, SharedArrayBuffer, and Atomics in EdgeHTML 16" (in en-US). 31 October 2017. https://blogs.windows.com/msedgedev/2017/10/31/optimizations-webassembly-sharedarraybuffer-atomics-edgehtml-16/. 
  43. ↑ "WebAssembly | Can I use... Support tables for HTML5, CSS3, etc". https://caniuse.com/wasm. 
  44. ↑ "asm.js | Can I use... Support tables for HTML5, CSS3, etc". https://caniuse.com/asmjs. 
  45. ↑ "WebAssembly Reference Types | Can I use... Support tables for HTML5, CSS3, etc". https://caniuse.com/wasm-reference-types. 
  46. ↑ "Wasmtime — a small and efficient runtime for WebAssembly & WASI". https://wasmtime.dev/. 
  47. ↑ "Roadmap". https://webassembly.org/roadmap/. 
  48. ↑ Wingo, Andy (2025-06-30). "WebAssembly: Yes, but for What?" (in EN). ACM Queue. doi:10.1145/3746171. https://queue.acm.org/detail.cfm?id=3746171. 
  49. ↑ Ball, Kevin (26 June 2018). "How WebAssembly is Accelerating the Future of Web Development". https://zendev.com/2018/06/26/webassembly-accelerating-future-web-development.html. 
  50. ↑ "LLVM 8.0.0 Release Notes — LLVM 8 documentation". https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#changes-to-the-webassembly-target. 
  51. ↑ 51.0 51.1 51.2 "Awesome WebAssembly Languages". 26 June 2018. https://github.com/appcypher/awesome-wasm-langs. 
  52. ↑ Krill, Paul (29 November 2017). "Direct WebAssembly compilation comes to Rust language" (in en). InfoWorld. https://www.infoworld.com/article/3239129/. 
  53. ↑ "AssemblyScript/assemblyscript". The AssemblyScript Project. 2020-09-09. https://github.com/AssemblyScript/assemblyscript. 
  54. ↑ Bonventre, Andrew (2018-08-24). "Go 1.11 is released". The Go Blog. https://go.dev/blog/go1.11. 
  55. ↑ "Frequently asked questions (FAQ) about Blazor". https://blazor.net/docs/introduction/faq.html. 
  56. ↑ "Bolero: F# in WebAssembly". https://fsbolero.io/. 
  57. ↑ "Running F# in WebAssembly with Bolero" (in English). Microsoft. 20 November 2019. Archived from the original. Error: If you specify |archiveurl=, you must also specify |archivedate=. https://archive.today/20250917195346/https://learn.microsoft.com/en-us/shows/on-dotnet/f-sharp-wasm. 
  58. ↑ "Pyodide: Bringing the scientific Python stack to the browser – Mozilla Hacks". https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser. 
  59. ↑ "Java to WebAssembly Compiler - CheerpJ". https://leaningtech.com/cheerpj/. 
  60. ↑ "JWebAssembly". 27 April 2023. https://github.com/i-net-software/JWebAssembly. 
  61. ↑ "TeaVM — Overview". https://www.teavm.org/docs/intro/overview.html. 
  62. ↑ "Bringing Kotlin to the Web". https://developers.googleblog.com/2023/05/bringing-kotlin-to-web.html. 
  63. ↑ Deleuze, Sébastien (2023-02-13). "The huge potential of Kotlin/Wasm". https://seb.deleuze.fr/the-huge-potential-of-kotlin-wasm/. 
  64. ↑ "Using the GHC WebAssembly backend". https://ghc.gitlab.haskell.org/ghc/doc/users_guide/wasm.html. 
  65. ↑ "Julia in the Browser". https://nextjournal.com/sdanisch/wasm-julia. 
  66. ↑ "MRuby in Your Browser". https://ruby.dj/. 
  67. ↑ Paul Krill (24 August 2020). "Ring language upgrade focuses on WebAssembly". InfoWorld. https://www.infoworld.com/article/3572395/ring-language-upgrade-focuses-on-webassembly.html. 
  68. ↑ "WebAssembly (Wasm) compilation". https://dart.dev/web/wasm/. 
  69. ↑ "stdweb - Rust". https://docs.rs/stdweb/*/stdweb/. "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." 
  70. ↑ "web_sys - Rust". https://docs.rs/web-sys/*/web_sys/. "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." 
  71. ↑ "The State of WebAssembly 2023". Scott Logic. 18 October 2023. https://blog.scottlogic.com/2023/10/18/the-state-of-webassembly-2023.html. 
  72. ↑ "Wasm needs a better memory management story · Issue #1397 · WebAssembly/design" (in en). https://github.com/WebAssembly/design/issues/1397. 
  73. ↑ "WebAssembly/content-security-policy" (in en). https://github.com/WebAssembly/content-security-policy. 
  74. ↑ "948834 - chromium - An open-source project to help move the web forward. - Monorail". https://bugs.chromium.org/p/chromium/issues/detail?id=948834&can=1&q=wasm-eval. 
  75. ↑ 75.0 75.1 "No way to use WebAssembly on Chrome without 'unsafe-eval' · Issue #7 · WebAssembly/content-security-policy" (in en). https://github.com/WebAssembly/content-security-policy/issues/7. 
  76. ↑ Cimpanu, Catalin (24 June 2018). "Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless" (in en-us). Bleeping Computer. https://www.bleepingcomputer.com/news/security/changes-in-webassembly-could-render-meltdown-and-spectre-browser-patches-useless/. 
  77. ↑ Sanders, James (25 June 2018). "How opaque WebAssembly code could increase the risk of Spectre attacks online" (in en). https://www.techrepublic.com/article/how-opaque-webassembly-code-could-increase-the-risk-of-spectre-attacks-online/. 
  78. ↑ R, Bhagyashree (30 October 2018). "Google Chrome 70 now supports WebAssembly threads to build multi-threaded web applications". https://hub.packtpub.com/google-chrome-70-now-supports-webassembly-threads-to-build-multi-threaded-web-applications/. 
  79. ↑ 79.0 79.1 Lonkar, Aishwarya; Chandrayan, Siddhesh (October 2018). "The dark side of WebAssembly". https://www.virusbulletin.com/virusbulletin/2018/10/dark-side-webassembly/. 
  80. ↑ Segura, Jérôme (29 November 2017). "Persistent drive-by cryptomining coming to a browser near you". Malwarebytes. https://blog.malwarebytes.com/cybercrime/2017/11/persistent-drive-by-cryptomining-coming-to-a-browser-near-you/. 
  81. ↑ "Recent Study Estimates That 50% of Websites Using WebAssembly Apply It for Malicious Purposes". https://www.infoq.com/news/2019/10/WebAssembly-wasm-malicious-usage/. 
  82. ↑ Musch, Marius; Wressnegger, Christian; Johns, Martin; Rieck, Konrad (June 2019). "New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild". Detection of Intrusions and Malware, and Vulnerability Assessment. Lecture Notes in Computer Science. 11543. Detection of Intrusions and Malware, and Vulnerability Assessment. pp. 23–42. doi:10.1007/978-3-030-22038-9_2. ISBN 978-3-030-22037-2. https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf. Retrieved 15 February 2022.  Slides (PDF)
  83. ↑ Aaron Hilbig, Daniel Lehmann, and Michael Pradel (April 2021). "An Empirical Study of Real-World WebAssembly Binaries: Security, Languages, Use Cases." (Archived April 2021) https://software-lab.org/publications/www2021.pdf
  84. ↑ Watt, Conrad (2018-01-08). "Mechanising and verifying the WebAssembly specification" (in en). Proceedings of the 7th ACM SIGPLAN International Conference on Certified Programs and Proofs. CPP 2018. Los Angeles CA USA: ACM. pp. 53–65. doi:10.1145/3167082. ISBN 978-1-4503-5586-5. https://dl.acm.org/doi/10.1145/3167082. Retrieved 9 August 2023. 
  85. ↑ Jangda, Abhinav; Powers, Bobby; Berger, Emery; Guha, Arjun (2019-05-31). "Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code". 2019 USENIX Annual Technical Conference. Renton, WA. pp. 107–120. OCLC 1106328738. https://www.usenix.org/sites/default/files/atc19-full-proceedings.pdf. Retrieved 2025-03-20. 
  86. ↑ Yan, Yutian; Tu, Tengfei; Zhao, Lijian; Zhou, Yuchen; Wang, Weihang (2 November 2021). "Understanding the performance of webassembly applications". Proceedings of the 21st ACM Internet Measurement Conference. pp. 533–549. doi:10.1145/3487552.3487827. ISBN 978-1-4503-9129-0. https://weihang-wang.github.io/slides/Yan-IMC21.pptx. 
  87. ↑ De Macedo, Joao; Abreu, Rui; Pereira, Rui; Saraiva, Joao (June 2022). "WebAssembly versus JavaScript: Energy and Runtime Performance". 2022 International Conference on ICT for Sustainability (ICT4S). pp. 24–34. doi:10.1109/ICT4S55073.2022.00014. ISBN 978-1-6654-8286-8. 
  88. ↑ "Zaplib post-mortem". April 2022. https://zaplib.com/docs/blog_post_mortem.html. 
  89. ↑ Denis, Frank (4 January 2023). "Performance of WebAssembly runtimes in 2023". https://00f.net/2023/01/04/webassembly-benchmark-2023/. 
  90. ↑ "WebAssembly Web API". https://webassembly.github.io/spec/web-api/index.html#security-considerations. 
  91. ↑ Kambale, Enoch. "WebAssembly in 2024: Promises, Challenges, and the Road Ahead" (in en). https://blog.enkambale.com/webassembly-2024-state-of-wasm/. 
  92. ↑ "WebAssembly System Interface Repo". GitHub / WebAssembly. 10 February 2020. https://github.com/WebAssembly/WASI. 
  93. ↑ "Additional background on Capabilities" (in en). bytecodealliance. 4 March 2022. https://github.com/bytecodealliance/wasmtime/blob/master/docs/WASI-capabilities.md. 
  94. ↑ "Standardizing WASI: A system interface to run WebAssembly outside the web – Mozilla Hacks - the Web developer blog". https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/. 
  95. ↑ "reference-sysroot Repo". GitHub / WebAssembly. 12 January 2020. https://github.com/WebAssembly/reference-sysroot. 
  96. ↑ "wasm-c-api Repo". GitHub / WebAssembly. 3 February 2020. https://github.com/WebAssembly/wasm-c-api. 
  97. ↑ NuxiNL/cloudlibc, Nuxi, 2024-12-06, https://github.com/NuxiNL/cloudlibc, retrieved 2025-04-01 
  98. ↑ Hykes, Solomon (March 27, 2019). "Solomon Hykes on X". https://x.com/solomonstre/status/1111004913222324225. 
  99. ↑ "Design Rationale". GitHub / WebAssembly / design. 1 October 2016. https://github.com/WebAssembly/design/blob/main/Rationale.md#why-a-stack-machine. 
  100. ↑ "WebAssembly High-Level Goals". GitHub / WebAssembly / design. 11 December 2015. https://github.com/WebAssembly/design/blob/main/HighLevelGoals.md. 
  101. ↑ "Portability - WebAssembly". https://webassembly.org/docs/portability/#assumptions-for-efficient-execution. 
  102. ↑ "Conventions — WebAssembly 1.0". https://webassembly.github.io/spec/core/syntax/conventions.html. 
  103. ↑ "Introduction — WebAssembly 1.0". https://webassembly.github.io/spec/core/intro/introduction.html?highlight=isa#scope. 
  104. ↑ "Instructions — WebAssembly 1.0". https://webassembly.github.io/spec/core/syntax/instructions.html. 
  105. ↑ Lively, Thomas (2021-02-19). "Final opcodes by tlively · Pull Request #452 · WebAssembly/simd · GitHub". Bytecode Alliance. https://github.com/WebAssembly/simd/pull/452. 
  106. ↑ Delendik, Yury (2021-02-19). "File wasm-tools/expr.rs at b5c3d98e40590512a3b12470ef358d5c7b983b15 · bytecodealliance/wasm-tools · GitHub". Bytecode Alliance. https://github.com/bytecodealliance/wasm-tools/blob/b5c3d98e40590512a3b12470ef358d5c7b983b15/crates/wast/src/ast/expr.rs. 
  107. ↑ "Update interpreter and text with finalized opcodes by ngzhian · Pull Request #486 · WebAssembly/simd" (in en). https://github.com/WebAssembly/simd/pull/486. 
  108. ↑ "WebAssembly/simd" (in en). https://github.com/WebAssembly/simd. 
  109. ↑ "How we made the JVM 40x faster". https://astojanov.github.io/blog/2017/12/20/scala-simd.html. 
  110. ↑ WebAssembly/relaxed-simd, WebAssembly, 2021-05-03, https://github.com/WebAssembly/relaxed-simd, retrieved 2021-05-14 
  111. ↑ "Wasm 3.0 Completed - WebAssembly" (in en). https://webassembly.org/news/2025-09-17-wasm-3.0/. 
  112. ↑ "Roadmap". March 2017. https://webassembly.org/roadmap/. 
  113. ↑ WebAssembly Community Group (January 2020). "WebAssembly Specification Release 1.0". https://webassembly.github.io/spec/core/binary/values.html#integers. 
  114. ↑ "Folded instructions". GitHub. https://webassembly.github.io/spec/core/text/instructions.html#folded-instructions.  / WebAssembly / spec
  115. ↑ "Modules (Binary)". https://webassembly.github.io/spec/core/syntax/modules.html. 
  116. ↑ "WebAssembly Binary Toolkit (wabt) demos". https://webassembly.github.io/wabt/demo/. 
  117. ↑ "WebAssembly control flow instructions - WebAssembly | MDN" (in en-US). 2025-11-23. https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/Control_flow. 
  118. ↑ Zakai, Alon (2011-10-22). "Emscripten: an LLVM-to-JavaScript compiler". Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion. OOPSLA '11 (New York, NY, USA: Association for Computing Machinery): 301–312. doi:10.1145/2048147.2048224. ISBN 978-1-4503-0942-4. https://doi.org/10.1145/2048147.2048224. 

 This article incorporates text from a free content work. Licensed under Apache License 2.0 License statement: Text Format, jfbastien; rossberg-chromium; kripken; titzer; s3ththompson; sunfishcode; lukewagner; flagxor; enricobacis; c3d; binji; andrewosh, GitHub. WebAssembly/design. To learn how to add open license text to HandWiki articles, please see this how-to page. For information on reusing text from HandWiki, please see the terms of use.



Retrieved from "https://handwiki.org/wiki/index.php?title=WebAssembly&oldid=4229334"