WebAssembly: Difference between revisions
No edit summary |
→top: def acro per MOS |
||
(46 intermediate revisions by 29 users not shown) | |||
Line 23: | Line 23: | ||
| file extensions = {{Unbulleted list|{{mono|.wat}} (text format)|{{mono|.wasm}} (binary format)}} |
| file extensions = {{Unbulleted list|{{mono|.wat}} (text format)|{{mono|.wasm}} (binary format)}} |
||
| file format = <!-- or: | file formats = --> |
| file format = <!-- or: | file formats = --> |
||
| influenced by = {{Hlist|[[asm.js]]|[[Google Native Client|PNaCl]]}} |
| influenced by = {{Hlist|[[asm.js]]|[[Google Native Client|PNaCl]]|[[Lisp (programming language)|Lisp]]}} |
||
| influenced = |
| influenced = |
||
}} |
}} |
||
'''WebAssembly''' ( |
'''WebAssembly''' ('''Wasm''') defines a [[software portability|portable]] [[binary code|binary-code]] format and a corresponding text format for [[executable|executable programs]]<ref>{{cite web |author1=Mozilla |title=Understanding WebAssembly text format |url=https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format |access-date=9 December 2019 |website=MDN Web Docs |language=en-US}} |
||
title=Understanding WebAssembly text format | |
|||
url=https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format | |
|||
website=MDN Web Docs |access-date=9 December 2019}} |
|||
</ref> as well as [[software]] interfaces for facilitating interactions between such programs and their host environment.<ref>{{Cite web| |
</ref> as well as [[software]] interfaces for facilitating interactions between such programs and their host environment.<ref>{{Cite web| |
||
url=https://webassembly.github.io/spec/core/intro/introduction.html| |
url=https://webassembly.github.io/spec/core/intro/introduction.html| |
||
Line 94: | Line 91: | ||
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 [[World Wide Web|Web]], where it will be executed [[client-side]] {{mdash}} 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 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 [[World Wide Web|Web]], where it will be executed [[client-side]] {{mdash}} 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,<ref name="Launch bug"/> and the first demonstration was executing [[Unity (game engine)|Unity]]'s ''Angry Bots'' in [[Firefox]],<ref name="Unity in Firefox"/> [[Google Chrome]],<ref name="V8 blog"/> and [[Microsoft Edge]].<ref name="Edge"/> The precursor technologies were [[asm.js]] from [[Mozilla]] and [[Google Native Client]],<ref name="techcrunch2015"/><ref name="PNaCl"/> and the initial implementation was based on the feature set of asm.js.<ref name="initial implementation"/> The asm.js technology already provides near-native code execution speeds<ref>{{Cite web|url=https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/|title=Staring at the Sun: Dalvik vs. ASM.js vs. Native|website=blog.mozilla.org|access-date=7 December 2019|quote=Even discarding the one score where asm.js did better, it executes at around 70% of the speed of native C++ code.}}</ref><ref>{{Cite book|last=Arjun|first=Jangda, Abhinav Powers, Bobby Berger, Emery Guha|url=http://worldcat.org/oclc/1106328738|title=Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code|date=2019-01-25|oclc=1106328738}}</ref> and can be considered a viable alternative for browsers that |
WebAssembly was first announced in 2015,<ref name="Launch bug"/> and the first demonstration was executing [[Unity (game engine)|Unity]]'s ''Angry Bots'' in [[Firefox]],<ref name="Unity in Firefox"/> [[Google Chrome]],<ref name="V8 blog"/> and [[Microsoft Edge]].<ref name="Edge"/> The precursor technologies were [[asm.js]] from [[Mozilla]] and [[Google Native Client]],<ref name="techcrunch2015"/><ref name="PNaCl"/> and the initial implementation was based on the feature set of asm.js.<ref name="initial implementation"/> The asm.js technology already provides near-native code execution speeds<ref>{{Cite web|url=https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/|title=Staring at the Sun: Dalvik vs. ASM.js vs. Native|website=blog.mozilla.org|date=August 2013 |access-date=7 December 2019|quote=Even discarding the one score where asm.js did better, it executes at around 70% of the speed of native C++ code.}}</ref><ref>{{Cite book|last=Arjun|first=Jangda, Abhinav Powers, Bobby Berger, Emery Guha|url=http://worldcat.org/oclc/1106328738|title=Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code|date=2019-01-25|oclc=1106328738}}</ref> 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.<ref name="MVP"/> In late September 2017, [[Safari (web browser)|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.<ref name="W3C-WD2018" /><ref name="W3C-CSWD2018" /><ref name="W3C-JIWD2018" /><ref name="W3C-WAWD2018" /> |
In March 2017, the design of the [[minimum viable product]] (MVP) was declared to be finished and the preview phase ended.<ref name="MVP"/> In late September 2017, [[Safari (web browser)|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.<ref name="W3C-WD2018" /><ref name="W3C-CSWD2018" /><ref name="W3C-JIWD2018" /><ref name="W3C-WAWD2018" /> |
||
Line 100: | Line 97: | ||
In June 2019, Chrome 75 was released with WebAssembly threads enabled by default.<ref>{{Cite web|title=WebAssembly Worker Based Threads - Chrome Platform Status|url=https://chromestatus.com/feature/5724132452859904|access-date=2022-02-19|website=chromestatus.com}}</ref> |
In June 2019, Chrome 75 was released with WebAssembly threads enabled by default.<ref>{{Cite web|title=WebAssembly Worker Based Threads - Chrome Platform Status|url=https://chromestatus.com/feature/5724132452859904|access-date=2022-02-19|website=chromestatus.com}}</ref> |
||
{{as of|April 2022|since=y|post=,}} WebAssembly 2.0 is in draft status,<ref>{{Cite web |title=WebAssembly Specification — WebAssembly 2.0 (Draft 2022-09-01) |url=https://webassembly.github.io/spec/core/ |access-date=2022-09-09 |website=webassembly.github.io}}</ref><ref>{{Cite web |title=WebAssembly 2.0 First Public Working Drafts {{!}} W3C News |date=19 April 2022 |url=https://www.w3.org/blog/news/archives/9509 |access-date=2022-09-09 |language=en-US}}</ref> which adds many [[SIMD]]-related instructions and a new v128 datatype, the ability for functions to return multiple values, and mass memory initialize/copy. |
|||
== Implementations == |
== Implementations == |
||
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.<ref name="nonweb">{{cite web|title=Non-Web Embeddings|url=https://webassembly.org/docs/non-web/|access-date=15 May 2019|work=WebAssembly}}</ref><ref name="nonwebsrc">{{cite web|title=Non-Web Embeddings|url=https://github.com/WebAssembly/design/blob/master/NonWeb.md|access-date=15 May 2019|work=[[GitHub]] / WebAssembly}}</ref> Since WebAssembly's runtime environments (RE) are low |
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.<ref name="nonweb">{{cite web|title=Non-Web Embeddings|url=https://webassembly.org/docs/non-web/|access-date=15 May 2019|work=WebAssembly}}</ref><ref name="nonwebsrc">{{cite web|title=Non-Web Embeddings|url=https://github.com/WebAssembly/design/blob/master/NonWeb.md|access-date=15 May 2019|work=[[GitHub]] / WebAssembly}}</ref> Since WebAssembly's runtime environments (RE) are low-level [[stack machine|virtual stack machines]] (akin to [[Java virtual machine|JVM]] or [[Adobe Flash|Flash VM]]) that can be embedded into host applications, some of them have found a way to standalone runtime environments like {{wdrl|Q119398768}} and {{wdrl|Q105554548}}.<ref name=":1">{{Cite web|title=Outside the web: standalone WebAssembly binaries using Emscripten · V8|url=https://v8.dev/blog/emscripten-standalone-wasm#running-in-wasm-runtimes|access-date=2020-07-28|website=v8.dev}}</ref><ref name="Wasmer">{{Cite web|title=Wasmer - The Universal WebAssembly Runtime|url=https://wasmer.io/|quote=Compile everything to WebAssembly. Run it on any OS or embed it into other languages.|access-date=2021-02-19|website=wasmer.io}}</ref> WebAssembly runtime environments are embedded in [[application server]]s to host "server-side" WebAssembly applications and in other applications to support [[plug-in (computing)|plug-in]]-based software extension architectures, e.g., "WebAssembly for Proxies" (proxy-wasm) which specifies a WebAssembly-based [[application binary interface|ABI]] for extending [[proxy server]]s.<ref>{{cite web |url=https://konghq.com/blog/engineering/proxy-wasm |last=Freese |first=Danny |date=2023-10-03 |df=mdy |title=Proxy-Wasm: It’s WebAssembly for Proxies |department=Blog |website=[[Kong Inc.|Kong]] |access-date=2024-05-06}}</ref><ref>{{cite web |url=https://github.com/proxy-wasm/spec |title=proxy-wasm/spec: WebAssembly for Proxies (ABI specification) |website=[[GitHub]] |access-date=2024-05-06}}</ref> |
||
=== Web browsers |
=== Web browsers<span class="anchor" id="Support"></span> === |
||
In November 2017, Mozilla declared support "in all major browsers",<ref name="in browsers"/> after WebAssembly was enabled by default in Edge 16.<ref name="Edge16"/> The support includes mobile web browsers for iOS and Android. <!-- While outdated, no longer supported, Android 4.4.4 KitKat and older versions don't have WebView support, Android 5 does. --> {{As of| |
In November 2017, Mozilla declared support "in all major browsers",<ref name="in browsers"/> after WebAssembly was enabled by default in Edge 16.<ref name="Edge16"/> The support includes mobile web browsers for iOS and Android. <!-- While outdated, no longer supported, Android 4.4.4 KitKat and older versions don't have WebView support, Android 5 does. --> {{As of|2024|3|post=,}} 99% of tracked web browsers <!-- 98.77%, 97.35% including browsers not tracked --> support WebAssembly (version 1.0),<ref name="canIuse.com"/> which is more than for its predecessor [[asm.js]], that is not supported by e.g. Safari web browser. <!-- For older browsers, Wasm can be compiled into asm.js by a JavaScript [[polyfill (programming)|polyfill]].<ref name="ars2015"/> --> 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.<ref>{{Cite web |title=WebAssembly Reference Types {{!}} Can I use... Support tables for HTML5, CSS3, etc |url=https://caniuse.com/wasm-reference-types |access-date=2024-03-03 |website=caniuse.com}}</ref> |
||
== Compilers == |
== Compilers == |
||
Line 116: | Line 113: | ||
As of version 8, a standalone [[Clang]] can compile [[C (programming language)|C]] and [[C++]] to Wasm.<ref>{{Cite web|title=LLVM 8.0.0 Release Notes — LLVM 8 documentation|url=https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#changes-to-the-webassembly-target|access-date=22 October 2019|website=releases.llvm.org}}</ref> |
As of version 8, a standalone [[Clang]] can compile [[C (programming language)|C]] and [[C++]] to Wasm.<ref>{{Cite web|title=LLVM 8.0.0 Release Notes — LLVM 8 documentation|url=https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#changes-to-the-webassembly-target|access-date=22 October 2019|website=releases.llvm.org}}</ref> |
||
Its initial aim was to support [[compilation (computing)|compilation]] from [[C (programming language)|C]] and [[C++]],<ref name="github.com"/> though support for other source [[programming language|languages]] such as [[Rust (programming language)|Rust]], [[.NET languages]]<ref name="Rust" /><ref>{{Cite web|title=Frequently asked questions (FAQ) about Blazor|url=https://blazor.net/docs/introduction/faq.html|access-date=18 June 2018|website=blazor.net}}</ref><ref name="Implementations" /> and [[AssemblyScript]]<ref>{{Citation|title=AssemblyScript/assemblyscript|date=2020-09-09|url=https://github.com/AssemblyScript/assemblyscript|publisher=The AssemblyScript Project|access-date=2020-09-09}}</ref> ([[TypeScript]]-like) is also emerging. After the MVP release, |
Its initial aim was to support [[compilation (computing)|compilation]] from [[C (programming language)|C]] and [[C++]],<ref name="github.com"/> though support for other source [[programming language|languages]] such as [[Rust (programming language)|Rust]], [[.NET languages]]<ref name="Rust" /><ref>{{Cite web|title=Frequently asked questions (FAQ) about Blazor|url=https://blazor.net/docs/introduction/faq.html|access-date=18 June 2018|website=blazor.net}}</ref><ref name="Implementations" /> and [[AssemblyScript]]<ref>{{Citation|title=AssemblyScript/assemblyscript|date=2020-09-09|url=https://github.com/AssemblyScript/assemblyscript|publisher=The AssemblyScript Project|access-date=2020-09-09}}</ref> ([[TypeScript]]-like) is also emerging. |
||
After the MVP release, WebAssembly added support for [[Thread (computing)#Multithreading|multithreading]] and [[Garbage collection (computer science)|garbage collection]]<ref>{{Cite web |title=A new way to bring garbage collected programming languages efficiently to WebAssembly · V8 |url=https://v8.dev/blog/wasm-gc-porting#demo-and-status |access-date=2023-12-11 |website=v8.dev}}</ref><ref>{{Cite web |title=WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome {{!}} Blog |url=https://developer.chrome.com/blog/wasmgc |access-date=2023-12-11 |website=Chrome for Developers |language=en}}</ref> which enabled compilation for garbage-collected programming languages like [[C Sharp (programming language)|C#]] (supported via [[Blazor]]), [[F Sharp (programming language)|F#]] (supported via Bolero<ref>{{Cite web|url=https://fsbolero.io/|title=Bolero: F# in WebAssembly|website=fsbolero.io|access-date=25 July 2019}}</ref> with help of Blazor), [[Python (programming language)|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 (programming language)|Python]],<ref>{{Cite web|title=Pyodide: Bringing the scientific Python stack to the browser – Mozilla Hacks - the Web developer blog|url=https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser|access-date=2020-09-09|website=Mozilla Hacks – the Web developer blog|language=en-US}}</ref> [[Julia (programming language)|Julia]],<ref>{{Cite web|url=https://nextjournal.com/sdanisch/wasm-julia|title=Julia in the Browser |website=nextjournal.com|access-date=9 April 2019}}</ref><ref>{{Cite web|url=https://github.com/JuliaPackaging/Yggdrasil/pull/2|title=WebAssembly platform by tshort · Pull Request #2 · JuliaPackaging/Yggdrasil|website=GitHub|language=en|access-date=9 April 2019}}</ref><ref>{{Citation|last=Fischer|first=Keno|title=GitHub - Keno/julia-wasm: Running julia on wasm.|date=22 July 2019|url=https://github.com/Keno/julia-wasm|access-date=25 July 2019}}</ref> and [[Ruby (programming language)|Ruby]].<ref>{{Cite web|url=https://ruby.dj/|title=MRuby in Your Browser|website=ruby.dj|access-date=25 July 2019}}</ref> |
A number of other languages have some support including [[Python (programming language)|Python]],<ref>{{Cite web|title=Pyodide: Bringing the scientific Python stack to the browser – Mozilla Hacks - the Web developer blog|url=https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser|access-date=2020-09-09|website=Mozilla Hacks – the Web developer blog|language=en-US}}</ref> [[Julia (programming language)|Julia]],<ref>{{Cite web|url=https://nextjournal.com/sdanisch/wasm-julia|title=Julia in the Browser |website=nextjournal.com|access-date=9 April 2019}}</ref><ref>{{Cite web|url=https://github.com/JuliaPackaging/Yggdrasil/pull/2|title=WebAssembly platform by tshort · Pull Request #2 · JuliaPackaging/Yggdrasil|website=GitHub|language=en|access-date=9 April 2019}}</ref><ref>{{Citation|last=Fischer|first=Keno|title=GitHub - Keno/julia-wasm: Running julia on wasm.|date=22 July 2019|url=https://github.com/Keno/julia-wasm|access-date=25 July 2019}}</ref> and [[Ruby (programming language)|Ruby]].<ref>{{Cite web|url=https://ruby.dj/|title=MRuby in Your Browser|website=ruby.dj|access-date=25 July 2019}}</ref> |
||
A number of systems can compile Java and other bytecode languages to JavaScript and WebAssembly. These include CheerpJ,<ref>{{cite web|access-date=2023-04-27|title=Java to WebAssembly Compiler - CheerpJ|url=https://leaningtech.com/cheerpj/}}</ref> |
A number of systems can compile Java and other bytecode languages to JavaScript and WebAssembly. These include CheerpJ,<ref>{{cite web|access-date=2023-04-27|title=Java to WebAssembly Compiler - CheerpJ|url=https://leaningtech.com/cheerpj/}}</ref> |
||
JWebAssembly<ref>{{citation|title=JWebAssembly|url=https://github.com/i-net-software/JWebAssembly|date=27 April 2023|via=GitHub}}</ref> and TeaVM.<ref>{{cite web|access-date=2023-04-27|title=TeaVM — Overview|url=https://www.teavm.org/docs/intro/overview.html|website=www.teavm.org}}</ref> These all take Java byte code .class files as input allowing other [[List of JVM languages|JVM languages]] like [[Apache Groovy|Groovy]], [[ |
JWebAssembly<ref>{{citation|title=JWebAssembly|url=https://github.com/i-net-software/JWebAssembly|date=27 April 2023|via=GitHub}}</ref> and TeaVM.<ref>{{cite web|access-date=2023-04-27|title=TeaVM — Overview|url=https://www.teavm.org/docs/intro/overview.html|website=www.teavm.org}}</ref> These all take Java byte code .class files as input allowing other [[List of JVM languages|JVM languages]] like [[Apache Groovy|Groovy]], and [[Scala (programming language)|Scala]] to be used as well. [[Kotlin (programming language)|Kotlin]] supports WebAssembly directly.<ref>{{Cite web |title=Bringing Kotlin to the Web |url=https://developers.googleblog.com/2023/05/bringing-kotlin-to-web.html |access-date=2023-12-11 |language=en}}</ref><ref>{{Cite web |last=Deleuze |first=Sébastien |date=2023-02-13 |title=The huge potential of Kotlin/Wasm |url=https://seb.deleuze.fr/the-huge-potential-of-kotlin-wasm/ |access-date=2023-12-11 |website=seb.deleuze.fr |language=en}}</ref> |
||
== Limitations == |
== Limitations == |
||
# In general, WebAssembly does not allow direct interaction with the [[Document Object Model|DOM]]. All interaction must flow through JavaScript interop. |
|||
# Absence of [[garbage collection (computer science)|garbage collection]] (although there are plans to address this.) |
|||
# Security considerations (discussed below) |
|||
⚫ | [[Web browser]]s do not allow WebAssembly code to directly access the [[Document Object Model]]. Wasm code must defer to [[JavaScript]] for this.{{Refn|group=note|For [[Rust (programming language)|Rust]]/Wasm development, third-party libraries can provide some of the necessary JavaScript I/O.<ref>{{Cite web|url=https://docs.rs/stdweb/*/stdweb/|title=stdweb - Rust|website=docs.rs|access-date=5 June 2019|quote=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.}}</ref><ref>{{Cite web|url=https://docs.rs/web-sys/*/web_sys/|title=web_sys - Rust|website=docs.rs|access-date=5 June 2019|quote=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.}}</ref>}} |
||
⚫ | |||
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.<ref>{{cite web |title=The State of WebAssembly 2023 |url=https://blog.scottlogic.com/2023/10/18/the-state-of-webassembly-2023.html |publisher=Scott Logic |date=18 October 2023 |access-date=14 March 2024}}</ref> |
|||
⚫ | 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."<ref>{{Cite web|title=Wasm needs a better memory management story · Issue #1397 · WebAssembly/design|url=https://github.com/WebAssembly/design/issues/1397|access-date=2021-02-15|website=GitHub|language=en}}</ref> |
||
⚫ | |||
All major |
All major browsers allow WebAssembly if Content-Security-Policy is not specified, or if "unsafe-eval" is used, but otherwise they behave differently.<ref>{{Cite web|title=WebAssembly/content-security-policy|url=https://github.com/WebAssembly/content-security-policy|access-date=2021-02-17|website=GitHub|language=en}}</ref> Chrome requires "unsafe-eval",<ref>{{Cite web|title=948834 - chromium - An open-source project to help move the web forward. - Monorail|url=https://bugs.chromium.org/p/chromium/issues/detail?id=948834&can=1&q=wasm-eval|access-date=2021-02-17|website=bugs.chromium.org}}</ref><ref name="ReferenceA">{{Cite web|title=No way to use WebAssembly on Chrome without 'unsafe-eval' · Issue #7 · WebAssembly/content-security-policy|url=https://github.com/WebAssembly/content-security-policy/issues/7|access-date=2021-02-17|website=GitHub|language=en}}</ref> though a worker thread can be a workaround.<ref name="ReferenceA"/> |
||
<!-- https://github.com/chrisknepper/android-messages-desktop/issues/135 Spell Check No Longer Working |
|||
In 2022, the [[startup company]] named Zaplib summarized in a blog why they were shutting down.<ref name="zaplib"/> Their goal had been to significantly increase the performance of existing [[web application|web apps]] by incrementally porting them to [[Rust (programming language)|Rust]]/Wasm. However, porting a customer's simulator from JavaScript only yielded a 5% improvement.<ref name="zaplib"/> 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."<ref name="zaplib">{{cite web |title=Zaplib post-mortem |url=https://zaplib.com/docs/blog_post_mortem.html |website=zaplib.com |date=April 2022 |access-date=14 March 2024}}</ref> |
|||
"electron-hunspell uses WebAssembly to implement Hunspell. [..] more of a security risk and thus compiling or instantiating a WebAssembly module (.wasm) is forbidden by what Google is sending in the content-security-policy header."--> |
|||
== Security considerations == |
== Security considerations == |
||
Line 142: | Line 139: | ||
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".<ref name="virus bulletin">{{cite web |last1=Lonkar |first1=Aishwarya |last2=Chandrayan |first2=Siddhesh |title=The dark side of WebAssembly |url=https://www.virusbulletin.com/virusbulletin/2018/10/dark-side-webassembly/ |website=[[Virus Bulletin]] |access-date=8 June 2019 |date=October 2018}}</ref> The speed and concealability of WebAssembly have led to its use in hidden [[Cryptocurrency#Mining|crypto mining]] on the website visitor's device.<ref name="virus bulletin"/><ref name="malwarebytes">{{cite web |last1=Segura |first1=Jérôme |title=Persistent drive-by cryptomining coming to a browser near you |url=https://blog.malwarebytes.com/cybercrime/2017/11/persistent-drive-by-cryptomining-coming-to-a-browser-near-you/ |publisher=[[Malwarebytes]] |access-date=8 June 2019 |date=29 November 2017}}</ref><ref name="forcepoint">{{cite web |last1=Neumann |first1=Robert |last2=Toro |first2=Abel |title=In-browser mining: Coinhive and WebAssembly |url=https://www.forcepoint.com/blog/x-labs/browser-mining-coinhive-and-webassembly |publisher=Forcepoint |access-date=8 June 2019 |language=en |date=19 April 2018}}</ref> [[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."<ref name="forcepoint" /> 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.<ref>{{Cite web|url=https://www.infoq.com/news/2019/10/WebAssembly-wasm-malicious-usage/|title=Recent Study Estimates That 50% of Websites Using WebAssembly Apply It for Malicious Purposes|website=InfoQ|access-date=3 November 2019}}</ref><ref>{{cite book |last1=Musch |first1=Marius |title=Detection of Intrusions and Malware, and Vulnerability Assessment |volume=11543 |pages=23–42 |last2=Wressnegger |first2=Christian |last3=Johns |first3=Martin |last4=Rieck |first4=Konrad |chapter=New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild |url=https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf |publisher=[[Detection of Intrusions and Malware, and Vulnerability Assessment]] |access-date=15 February 2022 |doi=10.1007/978-3-030-22038-9_2 |date=June 2019 |series=Lecture Notes in Computer Science |isbn=978-3-030-22037-2 |s2cid=184482682 |archive-date=26 July 2022 |archive-url=https://web.archive.org/web/20220726131621/https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf |url-status=dead }} [https://www.dimva2019.org/wp-content/uploads/sites/31/2019/06/DIMVA19-slides-2-R.pdf Slides (PDF)] {{Webarchive|url=https://web.archive.org/web/20191103054140/https://www.dimva2019.org/wp-content/uploads/sites/31/2019/06/DIMVA19-slides-2-R.pdf |date=3 November 2019 }}</ref> An April 2021 study from [[University of Stuttgart|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.<ref>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</ref> <!-- ORIGINAL URL WAS - DON'T KNOW HOW TO DO ARCHIVE-URL FOR CHAPTER: chapter-url=https://www.tu-braunschweig.de/Medien-DB/ias/pubs/2019-dimva.pdf --> |
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".<ref name="virus bulletin">{{cite web |last1=Lonkar |first1=Aishwarya |last2=Chandrayan |first2=Siddhesh |title=The dark side of WebAssembly |url=https://www.virusbulletin.com/virusbulletin/2018/10/dark-side-webassembly/ |website=[[Virus Bulletin]] |access-date=8 June 2019 |date=October 2018}}</ref> The speed and concealability of WebAssembly have led to its use in hidden [[Cryptocurrency#Mining|crypto mining]] on the website visitor's device.<ref name="virus bulletin"/><ref name="malwarebytes">{{cite web |last1=Segura |first1=Jérôme |title=Persistent drive-by cryptomining coming to a browser near you |url=https://blog.malwarebytes.com/cybercrime/2017/11/persistent-drive-by-cryptomining-coming-to-a-browser-near-you/ |publisher=[[Malwarebytes]] |access-date=8 June 2019 |date=29 November 2017}}</ref><ref name="forcepoint">{{cite web |last1=Neumann |first1=Robert |last2=Toro |first2=Abel |title=In-browser mining: Coinhive and WebAssembly |url=https://www.forcepoint.com/blog/x-labs/browser-mining-coinhive-and-webassembly |publisher=Forcepoint |access-date=8 June 2019 |language=en |date=19 April 2018}}</ref> [[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."<ref name="forcepoint" /> 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.<ref>{{Cite web|url=https://www.infoq.com/news/2019/10/WebAssembly-wasm-malicious-usage/|title=Recent Study Estimates That 50% of Websites Using WebAssembly Apply It for Malicious Purposes|website=InfoQ|access-date=3 November 2019}}</ref><ref>{{cite book |last1=Musch |first1=Marius |title=Detection of Intrusions and Malware, and Vulnerability Assessment |volume=11543 |pages=23–42 |last2=Wressnegger |first2=Christian |last3=Johns |first3=Martin |last4=Rieck |first4=Konrad |chapter=New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild |url=https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf |publisher=[[Detection of Intrusions and Malware, and Vulnerability Assessment]] |access-date=15 February 2022 |doi=10.1007/978-3-030-22038-9_2 |date=June 2019 |series=Lecture Notes in Computer Science |isbn=978-3-030-22037-2 |s2cid=184482682 |archive-date=26 July 2022 |archive-url=https://web.archive.org/web/20220726131621/https://www.sec.cs.tu-bs.de/pubs/2019a-dimva.pdf |url-status=dead }} [https://www.dimva2019.org/wp-content/uploads/sites/31/2019/06/DIMVA19-slides-2-R.pdf Slides (PDF)] {{Webarchive|url=https://web.archive.org/web/20191103054140/https://www.dimva2019.org/wp-content/uploads/sites/31/2019/06/DIMVA19-slides-2-R.pdf |date=3 November 2019 }}</ref> An April 2021 study from [[University of Stuttgart|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.<ref>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</ref> <!-- ORIGINAL URL WAS - DON'T KNOW HOW TO DO ARCHIVE-URL FOR CHAPTER: chapter-url=https://www.tu-braunschweig.de/Medien-DB/ias/pubs/2019-dimva.pdf --> |
||
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]]. |
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]].{{Cn|date=November 2023}} |
||
As WebAssembly supports only structured [[control flow]], it is amenable toward security verification techniques including [[symbolic execution]].<ref>{{Cite |
As WebAssembly supports only structured [[control flow]], it is amenable toward security verification techniques including [[symbolic execution]].<ref>{{Cite book|last=Watt|first=Conrad|title=Proceedings of the 7th ACM SIGPLAN International Conference on Certified Programs and Proofs |chapter=Mechanising and verifying the WebAssembly specification |date=2018-01-08|chapter-url=https://dl.acm.org/doi/10.1145/3167082|series=CPP 2018|language=en|location=Los Angeles CA USA|publisher=ACM|pages=53–65|doi=10.1145/3167082|isbn=978-1-4503-5586-5|s2cid=9401691|url=https://www.repository.cam.ac.uk/handle/1810/274174 }}</ref> Current efforts in this direction include the Manticore symbolic execution engine.<ref name="manticore" /> |
||
== WASI |
== WASI<span class="anchor" id="Beyond the Browser"></span> ==<!-- This section must eventually be merged into Implementations' sub section called like "host environments" as the WASI interface is (AFAIK) describes how some features must be provided by the host to the VM's executed .wasm programs. --> |
||
{{anchor|WASI}}WebAssembly System Interface (WASI) is a simple interface ([[application binary interface|ABI]] and [[application programming interface|API]]) designed by [[Mozilla]] intended to be portable to any platform.<ref name="WASI">{{cite web |url=https://github.com/WebAssembly/WASI |title=WebAssembly System Interface Repo |work=[[GitHub]] / WebAssembly|date=10 February 2020 }}</ref> It provides [[POSIX]]-like features like file I/O constrained by [[capability-based security]].<ref>{{cite web |title=Additional background on Capabilities |url=https://github.com/bytecodealliance/wasmtime/blob/master/docs/WASI-capabilities.md |website=GitHub |date=4 March 2022 |publisher=bytecodealliance |language=en}}</ref><ref>{{cite web |title=Standardizing WASI: A system interface to run WebAssembly outside the web – Mozilla Hacks - the Web developer blog |url=https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ |website=Mozilla Hacks – the Web developer blog}}</ref> There are also a few other proposed ABI/APIs.<ref name="reference-sysroot">{{cite web |url=https://github.com/WebAssembly/reference-sysroot |title=reference-sysroot Repo |work=[[GitHub]] / WebAssembly|date=12 January 2020 }}</ref><ref name="wasm-c-api">{{cite web |url=https://github.com/WebAssembly/wasm-c-api |title=wasm-c-api Repo |work=[[GitHub]] / WebAssembly|date=3 February 2020 }}</ref> |
{{anchor|WASI}}WebAssembly System Interface (WASI) is a simple interface ([[application binary interface|ABI]] and [[application programming interface|API]]) designed by [[Mozilla]] intended to be portable to any platform.<ref name="WASI">{{cite web |url=https://github.com/WebAssembly/WASI |title=WebAssembly System Interface Repo |work=[[GitHub]] / WebAssembly|date=10 February 2020 }}</ref> It provides [[POSIX]]-like features like file I/O constrained by [[capability-based security]].<ref>{{cite web |title=Additional background on Capabilities |url=https://github.com/bytecodealliance/wasmtime/blob/master/docs/WASI-capabilities.md |website=GitHub |date=4 March 2022 |publisher=bytecodealliance |language=en}}</ref><ref>{{cite web |title=Standardizing WASI: A system interface to run WebAssembly outside the web – Mozilla Hacks - the Web developer blog |url=https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ |website=Mozilla Hacks – the Web developer blog}}</ref> There are also a few other proposed ABI/APIs.<ref name="reference-sysroot">{{cite web |url=https://github.com/WebAssembly/reference-sysroot |title=reference-sysroot Repo |work=[[GitHub]] / WebAssembly|date=12 January 2020 }}</ref><ref name="wasm-c-api">{{cite web |url=https://github.com/WebAssembly/wasm-c-api |title=wasm-c-api Repo |work=[[GitHub]] / WebAssembly|date=3 February 2020 }}</ref> |
||
Line 152: | Line 149: | ||
WASI is influenced by [[Capsicum (Unix)#CloudABI|CloudABI]] and [[Capsicum (Unix)|Capsicum]]. |
WASI is influenced by [[Capsicum (Unix)#CloudABI|CloudABI]] and [[Capsicum (Unix)|Capsicum]]. |
||
Solomon Hykes, a co-founder of [[Docker (software)|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."<ref name="Wasmer-Docker" /> 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".<ref name="Wasmer-Docker">{{Cite web|title=The "Wasmer" WebAssembly Runtime is Generally Available|url=https://www.infoq.com/news/2021/01/wasmer-generally-available/|access-date=2021-02-19|website=InfoQ|language=en}}</ref> |
Solomon Hykes, a co-founder of [[Docker (software)|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."<ref name="Wasmer-Docker" /> [[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".<ref name="Wasmer-Docker">{{Cite web|title=The "Wasmer" WebAssembly Runtime is Generally Available|url=https://www.infoq.com/news/2021/01/wasmer-generally-available/|access-date=2021-02-19|website=InfoQ|language=en}}</ref> |
||
== Specification |
== Specification<span class="anchor" id="Features"></span>== |
||
=== Host environment === |
=== Host environment === |
||
Line 160: | Line 157: | ||
=== Virtual machine === |
=== Virtual machine === |
||
Wasm code (binary code, i.e. bytecode) is intended to be run on a [[software portability|portable]] virtual [[stack machine]] (VM).<ref name="stack machine" /> The VM is designed to be faster to parse and execute than JavaScript and to have a compact code representation.<ref name="github.com" /> |
Wasm code (binary code, i.e. bytecode) is intended to be run on a [[software portability|portable]] virtual [[stack machine]] (VM).<ref name="stack machine" /> The VM is designed to be faster to parse and execute than JavaScript and to have a compact code representation.<ref name="github.com" /> Any external functionality (like [[system call|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.<ref>{{Cite web|title=Portability - WebAssembly|url=https://webassembly.org/docs/portability/#assumptions-for-efficient-execution|access-date=2020-07-28|website=webassembly.org}}</ref><ref name=":1" /> |
||
=== Wasm program === |
=== Wasm program === |
||
Line 194: | Line 191: | ||
| access-date=2021-05-12 |
| access-date=2021-05-12 |
||
}} |
}} |
||
</ref> Those instructions, the "finalized opcodes"<ref>{{Cite web|title=Update interpreter and text with finalized opcodes by ngzhian · Pull Request #486 · WebAssembly/simd|url=https://github.com/WebAssembly/simd/pull/486|access-date=2021-05-14|website=GitHub|language=en}}</ref> are |
</ref> Those instructions, the "finalized opcodes"<ref>{{Cite web|title=Update interpreter and text with finalized opcodes by ngzhian · Pull Request #486 · WebAssembly/simd|url=https://github.com/WebAssembly/simd/pull/486|access-date=2021-05-14|website=GitHub|language=en}}</ref> 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<ref>{{Cite web|title=WebAssembly/simd|url=https://github.com/WebAssembly/simd|access-date=2021-05-14|website=GitHub|language=en}}</ref> 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.<ref>{{Citation|title=WebAssembly/relaxed-simd|date=2021-05-03|url=https://github.com/WebAssembly/relaxed-simd|publisher=WebAssembly|access-date=2021-05-14}}</ref> |
||
These SIMD opcodes are also portable and translate to native instruction sets like x64 and ARM. In contrast, neither Java's [[Java bytecode instruction listings|JVM]] |
These SIMD opcodes are also portable and translate to native instruction sets like x64 and ARM. In contrast, neither Java's [[Java bytecode instruction listings|JVM]] nor [[List of CIL instructions|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 [[intrinsic function|intrinsic]]s for x64 SIMD,<ref>{{Cite web|title=How we made the JVM 40x faster|url=https://astojanov.github.io/blog/2017/12/20/scala-simd.html<!--|quote=support for all 5912 Intel SIMD intrinsics from MMX to AVX-512.-->|access-date=2021-02-17|website=astojanov.github.io}}</ref> 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. |
||
==== Code representation ==== |
==== Code representation ==== |
||
Line 287: | Line 284: | ||
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 {{code|type}} emitted by the decompiler.<ref>{{cite web |title=Modules (Binary) |url=https://webassembly.github.io/spec/core/syntax/modules.html |website=WebAssembly 1.0}}</ref> The compiler and decompiler can be accessed online.<ref>{{cite web |title=WebAssembly Binary Toolkit (wabt) demos |url=https://webassembly.github.io/wabt/demo/ |website=webassembly.github.io}}</ref> |
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 {{code|type}} emitted by the decompiler.<ref>{{cite web |title=Modules (Binary) |url=https://webassembly.github.io/spec/core/syntax/modules.html |website=WebAssembly 1.0}}</ref> The compiler and decompiler can be accessed online.<ref>{{cite web |title=WebAssembly Binary Toolkit (wabt) demos |url=https://webassembly.github.io/wabt/demo/ |website=webassembly.github.io}}</ref> |
||
⚫ | |||
⚫ | |||
== See also == |
== See also == |
||
Line 299: | Line 293: | ||
* [[Compiler|Compilation]] |
* [[Compiler|Compilation]] |
||
* [[Porting|Software portability]] |
* [[Porting|Software portability]] |
||
⚫ | |||
⚫ | |||
== References == |
== References == |
||
Line 330: | Line 327: | ||
<ref name="MVP">{{Cite news|url=https://www.infoworld.com/article/3176681/|title=WebAssembly is now ready for browsers to use|last=Krill|first=Paul|date=6 March 2017|work=InfoWorld|access-date=23 December 2017|language=en}}</ref> |
<ref name="MVP">{{Cite news|url=https://www.infoworld.com/article/3176681/|title=WebAssembly is now ready for browsers to use|last=Krill|first=Paul|date=6 March 2017|work=InfoWorld|access-date=23 December 2017|language=en}}</ref> |
||
<ref name="canIuse.com">{{Cite web |title=WebAssembly {{!}} Can I use... Support tables for HTML5, CSS3, etc |url=https://caniuse.com/wasm |access-date= |
<ref name="canIuse.com">{{Cite web |title=WebAssembly {{!}} Can I use... Support tables for HTML5, CSS3, etc |url=https://caniuse.com/wasm |access-date=2024-03-01 |website=canIuse.com}}</ref> |
||
<ref name="in browsers">{{Cite web|url=https://blog.mozilla.org/blog/2017/11/13/webassembly-in-browsers/|title=WebAssembly support now shipping in all major browsers|website=The Mozilla Blog|language=en-US|access-date=21 November 2017}}</ref> |
<ref name="in browsers">{{Cite web|url=https://blog.mozilla.org/blog/2017/11/13/webassembly-in-browsers/|title=WebAssembly support now shipping in all major browsers|website=The Mozilla Blog|language=en-US|access-date=21 November 2017}}</ref> |
||
Line 336: | Line 333: | ||
<ref name="Edge16">{{Cite web|url=https://blogs.windows.com/msedgedev/2017/10/31/optimizations-webassembly-sharedarraybuffer-atomics-edgehtml-16/|title=Introducing new JavaScript optimizations, WebAssembly, SharedArrayBuffer, and Atomics in EdgeHTML 16|website=Microsoft Edge Dev Blog|language=en-US|access-date=21 November 2017|date=31 October 2017}}</ref> |
<ref name="Edge16">{{Cite web|url=https://blogs.windows.com/msedgedev/2017/10/31/optimizations-webassembly-sharedarraybuffer-atomics-edgehtml-16/|title=Introducing new JavaScript optimizations, WebAssembly, SharedArrayBuffer, and Atomics in EdgeHTML 16|website=Microsoft Edge Dev Blog|language=en-US|access-date=21 November 2017|date=31 October 2017}}</ref> |
||
<ref name="ars2015">{{Cite news|url=https://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly/|title=The Web is getting its bytecode: WebAssembly|last=Bright|first=Peter|date=18 June 2015|work=Ars Technica|access-date=23 December 2017|language=en-us}}</ref> |
<!--<ref name="ars2015">{{Cite news|url=https://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly/|title=The Web is getting its bytecode: WebAssembly|last=Bright|first=Peter|date=18 June 2015|work=Ars Technica|access-date=23 December 2017|language=en-us}}</ref> --> |
||
<ref name="Rust">{{Cite news|url=https://www.infoworld.com/article/3239129/|title=Direct WebAssembly compilation comes to Rust language|last=Krill|first=Paul|date=29 November 2017|work=InfoWorld|access-date=24 December 2017|language=en}}</ref> |
<ref name="Rust">{{Cite news|url=https://www.infoworld.com/article/3239129/|title=Direct WebAssembly compilation comes to Rust language|last=Krill|first=Paul|date=29 November 2017|work=InfoWorld|access-date=24 December 2017|language=en}}</ref> |
||
<ref name="next">{{Cite news|url=https://www.techworld.com.au/article/629123/|title=What's next for WebAssembly: GC, threads, debugging|last=Krill|first=Paul|date=26 October 2017|work=TechWorld|access-date=24 December 2017}}</ref> |
<!-- <ref name="next">{{Cite news|url=https://www.techworld.com.au/article/629123/|title=What's next for WebAssembly: GC, threads, debugging|last=Krill|first=Paul|date=26 October 2017|work=TechWorld|access-date=24 December 2017}}</ref> --> |
||
<ref name="Roadmap">{{Cite web|url=https://webassembly.org/roadmap/|title=Roadmap |website=WebAssembly |date=March 2017}}</ref> |
<ref name="Roadmap">{{Cite web|url=https://webassembly.org/roadmap/|title=Roadmap |website=WebAssembly |date=March 2017}}</ref> |
||
Line 368: | Line 365: | ||
* [https://www.w3.org/community/webassembly/ W3C Community Group] |
* [https://www.w3.org/community/webassembly/ W3C Community Group] |
||
* [https://github.com/WebAssembly/design WebAssembly Design] |
* [https://github.com/WebAssembly/design WebAssembly Design] |
||
* [https://whatext.com/wasm .wasm is WebAssembly Binary File] |
|||
* {{Citation|url=https://developer.mozilla.org/en-US/docs/WebAssembly|title=WebAssembly|website=MDN Web Docs|language=en-US}}{{snd}} with info on browser compatibility and specifications (WebAssembly JavaScript API) |
* {{Citation|url=https://developer.mozilla.org/en-US/docs/WebAssembly|title=WebAssembly|website=MDN Web Docs|language=en-US}}{{snd}} with info on browser compatibility and specifications (WebAssembly JavaScript API) |
||
Line 376: | Line 374: | ||
[[Category:Assembly languages]] |
[[Category:Assembly languages]] |
||
[[Category: |
[[Category:Internet properties established in 2015]] |
||
[[Category:World Wide Web Consortium standards]] |
[[Category:World Wide Web Consortium standards]] |
||
[[Category:Web programming]] |
[[Category:Web programming]] |
||
[[Category:Bytecodes]] |
[[Category:Bytecodes]] |
||
[[Category:Programming languages created in 2015]] |
Revision as of 18:19, 27 June 2024
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 2015World 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]
and first released in March 2017 , WebAssembly became aHistory
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.
Implementations
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]
Web browsers
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]
Compilers
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] and Ruby.[63]
A number of systems can compile Java and other bytecode languages to JavaScript and WebAssembly. These include CheerpJ,[64] JWebAssembly[65] and TeaVM.[66] 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.[67][68]
Limitations
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.[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 "unsafe-eval" is used, but otherwise they behave differently.[73] Chrome requires "unsafe-eval",[74][75] though a worker thread can be a workaround.[75]
In 2022, the startup company named Zaplib summarized in a blog why they were shutting down.[76] 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.[76] 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."[76]
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.[77][78][79] However, in order to explore these future language extensions, Google Chrome added experimental support for the WebAssembly thread proposal in October 2018.[80]
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".[81] The speed and concealability of WebAssembly have led to its use in hidden crypto mining on the website visitor's device.[81][82][77] 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."[77] 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.[83][84] 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.[85]
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.[86] Current efforts in this direction include the Manticore symbolic execution engine.[87]
WASI
WebAssembly System Interface (WASI) is a simple interface (ABI and API) designed by Mozilla intended to be portable to any platform.[88] It provides POSIX-like features like file I/O constrained by capability-based security.[89][90] There are also a few other proposed ABI/APIs.[91][92]
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."[93] 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".[93]
Specification
Host environment
The general standard provides core specifications for JavaScript API and details on embedding.[5]
Virtual machine
Wasm code (binary code, i.e. bytecode) is intended to be run on a portable virtual stack machine (VM).[94] 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.[95][9]
Wasm program
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.[96] Such 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) consisting of specific binary encodings of types of operations which are executed by the VM (without specifying how exactly they must be executed).[97] The list of instructions includes standard memory load/store instructions, numeric, parametric, control of flow instruction types and Wasm-specific variable instructions.[98]
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).[99][100] Those instructions, the "finalized opcodes"[101] 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[102] 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.[103]
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,[104] 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.
Code representation
In March 2017, the WebAssembly Community Group reached consensus on the initial (MVP) binary format, JavaScript API, and reference interpreter.[105] 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 |
---|---|---|
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.[106]
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.[107] 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))))))))
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.[108] The compiler and decompiler can be accessed online.[109]
See also
- Architecture Neutral Distribution Format (ANDF)
- UNCOL
- Java bytecode
- Common Language Runtime
- LLVM
- Compilation
- Software portability
Notes
- ^ According to official documentation, the Emscripten SDK may be used to create
.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] - ^ For Rust/Wasm development, third-party libraries can provide some of the necessary JavaScript I/O.[69][70]
References
- ^ "WebAssembly/design/Semantics.md". GitHub. Retrieved 23 February 2021.
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.
- ^ Mozilla. "Understanding WebAssembly text format". MDN Web Docs. Retrieved 9 December 2019.
- ^ "Introduction — WebAssembly 1.0". webassembly.github.io. Retrieved 18 June 2019.
WebAssembly is an open standard...
- ^ "Introduction — WebAssembly 1.0". webassembly.github.io. Retrieved 18 June 2019.
WebAssembly is a ... code format
- ^ a b "Conventions — WebAssembly 1.0". webassembly.github.io. Retrieved 17 May 2019.
WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure.
- ^ "Introduction — WebAssembly 1.0". webassembly.github.io. Retrieved 18 June 2019.
... 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.
- ^ "Introduction — WebAssembly 1.1". webassembly.github.io. Retrieved 19 February 2021.
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.
- ^ Haas, Andreas; Rossberg, Andreas; Schuff, Derek L.; Titzer, Ben L.; Holman, Michael; Gohman, Dan; Wagner, Luke; Zakai, Alon; Bastien, JF (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.
- ^ a b c "Outside the web: standalone WebAssembly binaries using Emscripten · V8". v8.dev. Retrieved 28 July 2020.
- ^ a b c "Wasmer - The Universal WebAssembly Runtime". wasmer.io. Retrieved 19 February 2021.
Compile everything to WebAssembly. Run it on any OS or embed it into other languages.
- ^ World Wide Web Consortium. "WebAssembly Core Specification". World Wide Web Consortium (W3). Retrieved 9 December 2019.
- ^ Couriol, Bruno. "WebAssembly 1.0 Becomes a W3C Recommendation and the Fourth Language to Run Natively in Browsers". infoq.com. Retrieved 9 December 2019.
- ^ "WebAssembly Specification — WebAssembly 1.1". webassembly.github.io. Retrieved 22 March 2021.
- ^ "Programming Languages Software Award". www.sigplan.org.
- ^ Bright, Peter (18 June 2015). "The Web is getting its bytecode: WebAssembly". Ars Technica. Condé Nast.
- ^ a b "New Bytecode Alliance Brings the Security, Ubiquity, and Interoperability of the Web to the World of Pervasive Computing". Mozilla. 12 November 2019. Retrieved 27 May 2019.
- ^ "Launch bug". GitHub / WebAssembly / design. 11 June 2015.
- ^ Wagner, Luke (14 March 2016). "A WebAssembly Milestone: Experimental Support in Multiple Browsers". Mozilla Hacks.
- ^ Thompson, Seth (15 March 2016). "Experimental support for WebAssembly in V8". V8 Blog.
- ^ Zhu, Limin (15 March 2016). "Previewing WebAssembly experiments in Microsoft Edge". Microsoft Edge dev blog.
- ^ Lardinois, Frederic (17 June 2015). "Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web". TechCrunch. Retrieved 24 December 2017.
- ^ Avram, Abel (31 May 2017). "Google Is to Remove Support for PNaCl". InfoQ. Retrieved 22 December 2017.
- ^ "WebAssembly: a binary format for the web". ②ality – JavaScript and more. 18 June 2015.
- ^ "Staring at the Sun: Dalvik vs. ASM.js vs. Native". blog.mozilla.org. August 2013. Retrieved 7 December 2019.
Even discarding the one score where asm.js did better, it executes at around 70% of the speed of native C++ code.
- ^ Arjun, Jangda, Abhinav Powers, Bobby Berger, Emery Guha (25 January 2019). Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code. OCLC 1106328738.
{{cite book}}
: CS1 maint: multiple names: authors list (link) - ^ a b Krill, Paul (6 March 2017). "WebAssembly is now ready for browsers to use". InfoWorld. Retrieved 23 December 2017.
- ^ "WebAssembly First Public Working Drafts". W3C. 15 February 2018. Retrieved 20 April 2018.
- ^ "WebAssembly Core Specification". W3C. 15 February 2018. Retrieved 20 April 2018.
- ^ "WebAssembly JavaScript Interface". W3C. 15 February 2018. Retrieved 20 April 2018.
- ^ "WebAssembly Web API". W3C. 15 February 2018. Retrieved 20 April 2018.
- ^ "WebAssembly Worker Based Threads - Chrome Platform Status". chromestatus.com. Retrieved 19 February 2022.
- ^ "WebAssembly Specification — WebAssembly 2.0 (Draft 2022-09-01)". webassembly.github.io. Retrieved 9 September 2022.
- ^ "WebAssembly 2.0 First Public Working Drafts | W3C News". 19 April 2022. Retrieved 9 September 2022.
- ^ "Non-Web Embeddings". WebAssembly. Retrieved 15 May 2019.
- ^ "Non-Web Embeddings". GitHub / WebAssembly. Retrieved 15 May 2019.
- ^ Freese, Danny (October 3, 2023). "Proxy-Wasm: It's WebAssembly for Proxies". Blog. Kong. Retrieved 2024-05-06.
- ^ "proxy-wasm/spec: WebAssembly for Proxies (ABI specification)". GitHub. Retrieved 6 May 2024.
- ^ "WebAssembly support now shipping in all major browsers". The Mozilla Blog. Retrieved 21 November 2017.
- ^ "Introducing new JavaScript optimizations, WebAssembly, SharedArrayBuffer, and Atomics in EdgeHTML 16". Microsoft Edge Dev Blog. 31 October 2017. Retrieved 21 November 2017.
- ^ "WebAssembly | Can I use... Support tables for HTML5, CSS3, etc". canIuse.com. Retrieved 1 March 2024.
- ^ "WebAssembly Reference Types | Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved 3 March 2024.
- ^ "Wasmtime — a small and efficient runtime for WebAssembly & WASI". wasmtime.dev. Retrieved 18 December 2020.
- ^ "Roadmap". Retrieved 7 December 2021.
- ^ Ball, Kevin (26 June 2018). "How WebAssembly is Accelerating the Future of Web Development". Archived from the original on 12 February 2019. Retrieved 22 October 2018.
- ^ a b "Awesome WebAssembly Languages". GitHub. 26 June 2018. Retrieved 15 February 2022.
- ^ Zakai, Alon [@kripken] (21 October 2019). "Emscripten has switched to the upstream LLVM wasm backend by default! / Details:https://groups.google.com/forum/#!topic/emscripten-discuss/NpxVAOirSl4 …" (Tweet). Retrieved 22 October 2019 – via Twitter.
- ^ "Developer's Guide - WebAssembly". webassembly.org. Retrieved 10 June 2019.
- ^ "Compiling a New C/C++ Module to WebAssembly". MDN Web Docs. Retrieved 10 June 2019.
- ^ "Building to WebAssembly — Emscripten 1.38.33 documentation". emscripten.org. Retrieved 10 June 2019.
- ^ "Emscripting a C library to Wasm | Web". Google Developers. Retrieved 10 June 2019.
- ^ "LLVM 8.0.0 Release Notes — LLVM 8 documentation". releases.llvm.org. Retrieved 22 October 2019.
- ^ a b "WebAssembly High-Level Goals". GitHub / WebAssembly / design. 11 December 2015.
- ^ Krill, Paul (29 November 2017). "Direct WebAssembly compilation comes to Rust language". InfoWorld. Retrieved 24 December 2017.
- ^ "Frequently asked questions (FAQ) about Blazor". blazor.net. Retrieved 18 June 2018.
- ^ AssemblyScript/assemblyscript, The AssemblyScript Project, 9 September 2020, retrieved 9 September 2020
- ^ "A new way to bring garbage collected programming languages efficiently to WebAssembly · V8". v8.dev. Retrieved 11 December 2023.
- ^ "WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome | Blog". Chrome for Developers. Retrieved 11 December 2023.
- ^ "Bolero: F# in WebAssembly". fsbolero.io. Retrieved 25 July 2019.
- ^ "Pyodide: Bringing the scientific Python stack to the browser – Mozilla Hacks - the Web developer blog". Mozilla Hacks – the Web developer blog. Retrieved 9 September 2020.
- ^ "Julia in the Browser". nextjournal.com. Retrieved 9 April 2019.
- ^ "WebAssembly platform by tshort · Pull Request #2 · JuliaPackaging/Yggdrasil". GitHub. Retrieved 9 April 2019.
- ^ Fischer, Keno (22 July 2019), GitHub - Keno/julia-wasm: Running julia on wasm., retrieved 25 July 2019
- ^ "MRuby in Your Browser". ruby.dj. Retrieved 25 July 2019.
- ^ "Java to WebAssembly Compiler - CheerpJ". Retrieved 27 April 2023.
- ^ JWebAssembly, 27 April 2023 – via GitHub
- ^ "TeaVM — Overview". www.teavm.org. Retrieved 27 April 2023.
- ^ "Bringing Kotlin to the Web". Retrieved 11 December 2023.
- ^ Deleuze, Sébastien (13 February 2023). "The huge potential of Kotlin/Wasm". seb.deleuze.fr. Retrieved 11 December 2023.
- ^ "stdweb - Rust". docs.rs. Retrieved 5 June 2019.
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.
- ^ "web_sys - Rust". docs.rs. Retrieved 5 June 2019.
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.
- ^ "The State of WebAssembly 2023". Scott Logic. 18 October 2023. Retrieved 14 March 2024.
- ^ "Wasm needs a better memory management story · Issue #1397 · WebAssembly/design". GitHub. Retrieved 15 February 2021.
- ^ "WebAssembly/content-security-policy". GitHub. Retrieved 17 February 2021.
- ^ "948834 - chromium - An open-source project to help move the web forward. - Monorail". bugs.chromium.org. Retrieved 17 February 2021.
- ^ a b "No way to use WebAssembly on Chrome without 'unsafe-eval' · Issue #7 · WebAssembly/content-security-policy". GitHub. Retrieved 17 February 2021.
- ^ a b c "Zaplib post-mortem". zaplib.com. April 2022. Retrieved 14 March 2024.
- ^ a b c Neumann, Robert; Toro, Abel (19 April 2018). "In-browser mining: Coinhive and WebAssembly". Forcepoint. Retrieved 8 June 2019.
- ^ Cimpanu, Catalin (24 June 2018). "Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless". Bleeping Computer. Retrieved 8 June 2019.
- ^ Sanders, James (25 June 2018). "How opaque WebAssembly code could increase the risk of Spectre attacks online". Tech Republic. Retrieved 9 June 2019.
- ^ R, Bhagyashree (30 October 2018). "Google Chrome 70 now supports WebAssembly threads to build multi-threaded web applications". Packt Pub. Retrieved 9 June 2019.
- ^ a b Lonkar, Aishwarya; Chandrayan, Siddhesh (October 2018). "The dark side of WebAssembly". Virus Bulletin. Retrieved 8 June 2019.
- ^ Segura, Jérôme (29 November 2017). "Persistent drive-by cryptomining coming to a browser near you". Malwarebytes. Retrieved 8 June 2019.
- ^ "Recent Study Estimates That 50% of Websites Using WebAssembly Apply It for Malicious Purposes". InfoQ. Retrieved 3 November 2019.
- ^ 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 (PDF). Lecture Notes in Computer Science. Vol. 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. S2CID 184482682. Archived from the original (PDF) on 26 July 2022. Retrieved 15 February 2022. Slides (PDF) Archived 3 November 2019 at the Wayback Machine
- ^ 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
- ^ Watt, Conrad (8 January 2018). "Mechanising and verifying the WebAssembly specification". 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. S2CID 9401691.
- ^ "Symbolically Executing WebAssembly in Manticore". 31 January 2020. Retrieved 10 February 2020.
- ^ "WebAssembly System Interface Repo". GitHub / WebAssembly. 10 February 2020.
- ^ "Additional background on Capabilities". GitHub. bytecodealliance. 4 March 2022.
- ^ "Standardizing WASI: A system interface to run WebAssembly outside the web – Mozilla Hacks - the Web developer blog". Mozilla Hacks – the Web developer blog.
- ^ "reference-sysroot Repo". GitHub / WebAssembly. 12 January 2020.
- ^ "wasm-c-api Repo". GitHub / WebAssembly. 3 February 2020.
- ^ a b "The "Wasmer" WebAssembly Runtime is Generally Available". InfoQ. Retrieved 19 February 2021.
- ^ "Design Rationale". GitHub / WebAssembly / design. 1 October 2016.
- ^ "Portability - WebAssembly". webassembly.org. Retrieved 28 July 2020.
- ^ "Conventions — WebAssembly 1.0". webassembly.github.io. Retrieved 12 November 2019.
- ^ "Introduction — WebAssembly 1.0". webassembly.github.io. Retrieved 17 May 2019.
- ^ "Instructions — WebAssembly 1.0". webassembly.github.io. Retrieved 12 November 2019.
- ^ Lively, Thomas (19 February 2021) [Pull Request opened on 2021-02-05]. "Final opcodes by tlively · Pull Request #452 · WebAssembly/simd · GitHub". Bytecode Alliance. Retrieved 12 May 2021 – via GitHub.
- ^ Delendik, Yury (19 February 2021) [SIMD changes committed on 2021-02-19]. "File wasm-tools/expr.rs at b5c3d98e40590512a3b12470ef358d5c7b983b15 · bytecodealliance/wasm-tools · GitHub". Bytecode Alliance. Retrieved 12 May 2021 – via GitHub.
- ^ "Update interpreter and text with finalized opcodes by ngzhian · Pull Request #486 · WebAssembly/simd". GitHub. Retrieved 14 May 2021.
- ^ "WebAssembly/simd". GitHub. Retrieved 14 May 2021.
- ^ WebAssembly/relaxed-simd, WebAssembly, 3 May 2021, retrieved 14 May 2021
- ^ "How we made the JVM 40x faster". astojanov.github.io. Retrieved 17 February 2021.
- ^ "Roadmap". WebAssembly. March 2017.
- ^ WebAssembly Community Group (January 2020). "WebAssembly Specification Release 1.0". Retrieved 13 January 2020.
- ^ "Folded instructions". GitHub. / WebAssembly / spec
- ^ "Modules (Binary)". WebAssembly 1.0.
- ^ "WebAssembly Binary Toolkit (wabt) demos". webassembly.github.io.
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.
External links
- Official website
- W3C Community Group
- WebAssembly Design
- .wasm is WebAssembly Binary File
- "WebAssembly", MDN Web Docs – with info on browser compatibility and specifications (WebAssembly JavaScript API)