Talk:WebAssembly

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

a few sources[edit]


WebAssembly is byte code?[edit]

I am most definitely not an expert in this matter, however, the article currently says "WebAssembly is portable byte code…", but according to this: http://www.2ality.com/2015/06/web-assembly.html … "WebAssembly is not bytecode: Bytecode is linear and (usually) stack-, register- or SSA-based, WebAssembly is a binary format for an abstract syntax tree (AST)…" I might just change this anyway. Thoughts?

Damienivan (talk) 06:42, 29 July 2015 (UTC)[reply]

Changing that would be fine by me (and I wrote it in the first place). It would be nice if you added the AST info at the same time. Thue (talk) 10:03, 29 July 2015 (UTC)[reply]

Edge is a major browser[edit]

@Ajfweb: reverted listing Edge with the argument Revert. Edge is not a major browser by market share. However, looking at browser statistics, Edge has a 2% market share - way above the next browser, Opera. And Edge is the default browser for Windows 10, which means 1) it will grow explosively as Windows 10 gains market share 2) it is unignorable by all web developers. Being unignorable by web developers makes it a major browser.

The list of browsers is there because WebAssembly's success depends on WebAssembly being present in the important browsers. Obviously Edge is an important browser for this purpose. Hence Edge belongs on this list. Thue (talk) 13:11, 4 September 2015 (UTC)[reply]

Hello, Thue.
First, 2% isn't major, even if Edge was one of the only two web browsers in the world.
Second, your source is a version-by-version comparison, while we are talking aggregates here. NetMarketShare.com can generate aggregates too. Here: Edge does not even show up on the chart. (If you are wondering why, you should study the difference between percentage and percentage point.)
Third, I already find any mention of Internet Explorer or any other Microsoft web browser undue; it is like comparing "people from Asia" with "people from Panama". Microsoft is a huge company in which internal departments compete. The people responsible for Edge and Internet Explorer might know zilch about WebAsm. People from Mozilla, however, work on nothing but Firefox.
Best regards,
Codename Lisa (talk) 16:30, 4 September 2015 (UTC)[reply]
Uhh, I am flabbergasted at your reply. "Microsoft is a huge company in which internal departments compete. The people responsible for Edge and Internet Explorer might know zilch about WebAsm."? Obviously the people from the MS browser development teams are involved with webasm - why else would Microsoft be involved in a programming language which only has relevance for browsers? And as I said: Edge is the default browser in Windows 10, that means it will be widely used shortly, making it a must-support browser for anyone designing webpages. And 2% is already enough in itself that serious web developers will test in Edge. Thue (talk) 20:56, 4 September 2015 (UTC)[reply]
@Thue: Well, perhaps you wouldn't have been flabbergasted if you had my experiences. I traced the claim to its source and then traced the source's source. It comes from Mike Holman, who claims to work on Chakra's performance. And with this find comes a torrent of similar past cases. Let me show you:
  • Do you know who developed HD Photo and made it JPEG XR? One person called Bill Crow. He worked in Seadragon Software group but I am yet to find evidence that anybody else inside Microsoft worked on it. On the contrary, given how Microsoft is uninterested in it, as well as its slapdash implementation, it all seems a one person work.
  • Also, do you know who develops paint.net? One Microsoft employee called Rick Brewster. paint.net is not even Microsoft property.
Likewise, so far only one person inside Microsoft seems connected to WebAsm. Any evidence that Microsoft has directives to pursue this course? Or is it just one developer interested in his own field of work? It is true that Ars Technica said "Microsoft" but I would have said that if worked for Ars Technica.
And as for "that means it will be widely used shortly"; if that is so, then please wait a short while! You can add it if and when it becomes widely used. WP:CRYSTAL.
Best regards,
Codename Lisa (talk) 15:58, 5 September 2015 (UTC)[reply]

WebAssembly text format[edit]

I think this article would be more complete if it defines the WebAssembly text format instead of using terms like "text "linear assembly bytecode" (intermediate representation)". It would improve clarity as to the current usage, and show that the two formats in 'common' use are the text format and the binary format.

https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format

The table of 3 different views of source code should have the text format in s-expressions in the 2nd column.

I'll try to make some edits if I have time. — Preceding unsigned comment added by Bobcompu (talk • contribs) 00:19, 31 July 2017 (UTC)[reply]

Maybe " ;; the name $f0 is the same as 0 here" is actually about $p0 ? Because call $f0 is seems to be legit recursion. ММЛ (talk) 19:54, 5 October 2022 (UTC)[reply]

"JavaScript Applet"?[edit]

Sounds like something of the 90s and as far as I know isn't a thing. Perhaps someone confused Java/JS and jumped to Java Applet?

Could probably be worded better

--Zander Brown (talk) 21:53, 18 June 2018 (UTC)[reply]

Improving Example[edit]

The "bytecode" example may be more meaningful if commented, perhaps below the 3 panels, similar to this (guessed) example: 

 get_local 0  // put '0' on stack
 i64.eqz  // compare to top of stack
 if (result i64) // if equal
     i64.const 1  // put '1' on stack
 else
     get_local 0  // get parameter from stack
     get_local 0  
     i64.const 1  // define constant '1'
     i64.sub  // subtract
     call 0   // perform function on the stack
     i64.mul  // multiple result
 end  — Preceding unsigned comment added by 146.233.255.213 (talk) 16:17, 20 July 2018 (UTC)[reply]

Sources[edit]

Pmffl, please note that all material in Wikipedia mainspace, including everything in articles, lists and captions, must be verifiable[1] and that source material should be carefully summarized or rephrased without changing its meaning or implication.[2] Unless you can provide a reliable source that explicitly says that the purpose of WebAssembly is to "enable the JavaScript engine of a web browser to execute web page scripts nearly as fast as native machine code", we can not and should not write that in the article.--Anders Feder (talk) 18:01, 9 May 2019 (UTC)[reply]

Alexander_Davronov and others have been adding a section about Wasm "utilizing" Clang or other compilers. This is inaccurate, and once again not backed up by sources. Wasm is a compilation target. A file format. It doesn't "utilize" anything. Whether you use a compiler at all is irrelevant to Wasm itself. Unless someone rectifies it in accordance with WP:V, I propose removing the section per WP:UNSOURCED.--Anders Feder (talk) 20:07, 10 June 2019 (UTC)[reply]

@Anders Feder: Wrong. The last time section was supplied with "clang" by @71.135.5.88: (see this edit), not by me. I have fixed that and added sources on Emscripten according to official docs. Checkout here. DAVRONOVA.A. ✉ ⚑ 20:58, 10 June 2019 (UTC)[reply]
@Alexander Davronov: It is not wrong - you added the original section here, which is what I was referring to. None of the sources you have added state that WebAssembly "utilizes" or "requires" Emscripten. They give simplistic EXAMPLES using Emscripten, nothing of which constitute a requirement. The spec specifically says that WebAssembly "does not privilege any particular language, programming model, or object model". Adding random links that doesn't support your claim doesn't change anything and is just disruptive editing wasting everyone's time. Unless I'm provided with sources that "directly supports the material"[3], I'm removing the section per WP:UNSOURCED.--Anders Feder (talk) 16:50, 11 June 2019 (UTC)[reply]
@Anders Feder: Refrain from removing anything. Just correct it and provide appropriate sources. I think the basic problem here is misspelling of how actually to use WebAssembly in web browser (which it was created for and what I wanted to say). The Emscripten is the only tool mentioned on the official web site and I consider that it worth to mention it (there are various others actually). You can't simply ignore it by saying it's unsourced.
The pec specifically says that WebAssembly ... — Yeah, cause WebAssembly is a set of standards (ISA and assembly lang) which may be implemented by anyone and coupled with any chosen environment. Currently most often it is used in web browsers. Emscripten and few other are the only tools which may be used to compile source-language to browser-consumable WASM format. You are free here to fix everything as you wish.
Adding random links that doesn't support your claim doesn't — Seems like it's whole new level of ignorance. Some of these are actually official web site links. DAVRONOVA.A. ✉ ⚑ 19:59, 11 June 2019 (UTC)[reply]
@Alexander Davronov: "The burden to demonstrate verifiability lies with the editor who adds or restores material".[4] Providing reliable sources for falsehoods that you have introduced into the article is not the responsibility of me or anyone else - it is the responsibility of you. If you don't want to or are not able to fulfill that responsibility, the material should be removed. If you are unwilling to or incapable of accepting and abiding by this or any of Wikipedia's other editing policies, you should be banned from editing to stop you from wasting the time of those here to improve the article.--Anders Feder (talk) 21:30, 11 June 2019 (UTC)[reply]

Delete WebAssembly Malware Section[edit]

This axe-grinding section against WASM is ridiculous and has no place on Wikipedia:

1) Many languages utilize compiled code. The web browser itself is compiled code. The job of analyzing software has always required decoding compiled output, and all languages are compatible with obfuscation and compilation. The common framework for compiling C apps for the web, Emscripten, actually emitted a variant of JavaScript called asm.js, which was JITted into reasonably fast native code in modern browsers. It wasn't binary, it wasn't pretty, whatever.

2) Sometimes cryptomining uses WASM, sometimes it uses WebGL, sometimes it uses straight JS. Somebody probably used Flash at some point. The web is a platform where it wasn't supposed to matter if a random website runs code on your device. No problem mentioning this in discussion of cryptomining, but WASM does not bear the transformative burden of adding controversial CPU resources to the web. There are other mechanisms in the same realm, always have been (remember Java and Flash? Remember Google's V8 making JS suddenly fast?).

3) High frequency timing attacks are a nasty issue; the fundamental mechanisms of process isolation don't actually work like people think they work (it's not about logic, it's about isolation / the separation of shared resources). But they're not WASM's issue. Quite a bit of the browser surface exposes variability of execution time dependent on external secrets. This is probably the most legitimate of the claims, but I know of no *Malware* that has ever used WASM/Spectre to break process boundaries.

I don't think 3 is enough to justify a section, and 1 and 2 are clearly derogatory. Could be a legitimate Security Considerations section -- WASM occupies an interesting place in the ecosystem, and it's not necessarily an easy one.DanKaminsky (talk) 17:09, 24 September 2019 (UTC) (Dan Kaminsky)[reply]

Hi Dan. Welcome to Wikipedia and thank you for the suggestion. I've made a first cut at improving this section [5]. Please let us know if you would like to suggest further improvements to this or other articles. Jehochman Talk 18:05, 24 September 2019 (UTC)[reply]
Thank you, Jehochman! Somebody reminded me I could actually try to help, and I was like...actually, I can. Let me scrounge up some sources for the interesting security properties of WASM, and that'll make for a fair section.DanKaminsky (talk) 19:45, 24 September 2019 (UTC)[reply]
If you suggest some sources (which you can probably dig up much more quickly than I could), I'll try to use them to make a more thorough discussion of the security concerns, both positive and negative, as they may be. Jehochman Talk 01:38, 25 September 2019 (UTC)[reply]
OMG! The amount I daily scout and delete of the wasm malware are enormous! It should deserve and section. VScode fanboy (talk) 13:28, 1 April 2022 (UTC)[reply]

WASM vs. Wasm. And WASI vs. Wasi[edit]

Why is it Wasm and not WASM?

Why not Wasi then instead of WASI?

--Mortense (talk) 13:00, 11 February 2020 (UTC)[reply]

Fourth language?[edit]

"alongside HTML, CSS, and JavaScript, is the fourth language to run natively in browsers"

HTML and CSS do not "run" in browsers. They are not even programming languages. If the remark is about programming languages, then it's the second, after JS. If not, then it's not "run", but "supported" or something like that. I won't bother to change it though; a stupid bot or a knows-all-better admin would revert it in five seconds anyway.

How many APIs?[edit]

Re "for JavaScript API" (sub section Host environment):

Is there one API ("the JavaScript API") or several ("JavaScript APIs")? --Mortense (talk) 23:51, 26 September 2020 (UTC)[reply]

Compactness[edit]

The article stresses that Wasm is compact. At first glance, the example shown seems to corroborate this, as the Wasm is a few bytes shorter. But if you take into account that the Wasm doesn't contain the descriptive function name and that the C representation isn't the shortest possible, the picture changes: 

Wasm:                                49 bytes (Wasm)
int f(int n){return n?n*f(n-1):1;}   34 bytes (C)
function f(n){return n?n*f(n-1):1}   34 bytes (JS)
f=n=>n?n*f(n-1):1                    17 bytes (JS arrow function)

I'm not trying to make a point about code golfing here, and I don't think compactness was the primary motivation behind Wasm in the first place. Still, if the article is going to claim that Wasm is compact, it should cite a somewhat representative benchmark where the size of Wasm bytecode combined with the infrastructure to use it is compared to minified JS for example.

remove textbin.xyz 185.187.78.247 (talk) 22:24, 19 September 2023 (UTC)[reply]

The examples you provided are source code and the counts you used are just the source code lengths. That is not what is being discussed here. The article talks about the compiled executable or encoded bytecode. The provided source explicitly states that (size- and load-time-efficient binary format).[1] For reference, JS does not have a universal bytecode, only the actual textual source, since it was conceived as a scripting format. C/C++ does not have a bytecode either, only the source and the compiled machine code. The most relevant comparison would be Java which does have bytecode. Perhaps, the meaning of the word "compact" could be clarified in the article.
[1] https://github.com/WebAssembly/design/blob/main/HighLevelGoals.md Anton.bersh (talk) 07:26, 21 September 2023 (UTC)[reply]

Update GC and Kotlin info[edit]

COI reason: I'm an engineer paid by JetBrains to develop Kotlin programming language, and I want to update outdated information about Kotlin support on this page.

  • Specific text to be added or removed: 1. In "After the MVP release, there are plans to support multithreading and garbage collection which would make WebAssembly a compilation target for garbage-collected programming languages like [...]". change to "After the MVP release, WebAssembly added support multithreading and garbage collection which enabled compilation for garbage-collected programming languages like [...]". 2. Add Kotlin (programming language) to the list of languages supporting in WebAssembly directly (without .class Java bytecode).
  • Reason for the change: 1. WebAssembly standardised garbage collection and threads. 2. Kotlin has a official support for a direct WebAssembly compilation (without JVM bytecode).
  • References supporting change:

Wasm garbage collection is a standardised and enabled by default in Chrome and Firefox: https://webassembly.org/roadmap/, https://v8.dev/blog/wasm-gc-porting#demo-and-status, https://developer.chrome.com/blog/wasmgc, https://www.mozilla.org/en-US/firefox/120.0/releasenotes/ (Under Web Platform section)

Wasm threads and atomics are standardised: https://webassembly.org/roadmap/,

Kotlin supports WebAssembly compilation: https://blog.jetbrains.com/kotlin/2023/12/kotlin-for-webassembly-goes-alpha/, https://kotl.in/wasm, https://v8.dev/blog/wasm-gc-porting#getting-started, https://developers.googleblog.com/2023/05/bringing-kotlin-to-web.html, https://seb.deleuze.fr/the-huge-potential-of-kotlin-wasm/, 144.178.97.2 (talk) 13:20, 11 December 2023 (UTC)[reply]

🟡  Edit request partially implemented  
I didn't include some of the first party sources (JetBrains blog, kotl.in sites) but there is more than enough to cover this topic. Changes completed. Lewcm Talk to me! 18:57, 11 December 2023 (UTC)[reply]

Blazor and WasmGC[edit]

is there any credible source confirming that Blazor uses WasmGC? afaik, blazor was created before wasmgc was implemented in browsers, so imo blazor most probably uses its own gc implementation (based on mono runtime).

look at open issues (or closed without implementation): https://github.com/dotnet/runtime/issues/82974 https://github.com/WebAssembly/gc/issues/77 89.70.30.119 (talk) 10:34, 24 February 2024 (UTC)[reply]

the whole following sentence needs to be rewritten to dissociate Blazor from WasmGC:

After the MVP release, WebAssembly added support for multithreading and garbage collection[54][55] which enabled compilation for garbage-collected programming languages like C# (supported via Blazor), F# (supported via Bolero[56] with help of Blazor), Python, and even JavaScript where the browser's just-in-time compilation speed is considered too slow. — Preceding unsigned comment added by 91.214.5.128 (talk) 09:59, 27 February 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:WebAssembly&oldid=1210585886"