This is the
talk page for discussing improvements to the
WebAssembly article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||
|
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
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)
@ 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)
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)
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)
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)
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)
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)
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)
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)
Why is it Wasm and not WASM?
Why not Wasi then instead of WASI?
-- Mortense ( talk) 13:00, 11 February 2020 (UTC)
"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.
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)
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)
This edit request by an editor with a conflict of interest has now been answered. |
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.
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)
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)
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)
Consider adding a sentence or paragraph about example websites that use web assembly. For example, does lichess use webassembly for its chess analysis and ai?
Consider adding a sentence or paragraph about what old technologies web assembly is replacing. How was this done before webassembly was invented? Is this a replacement for Adobe flash? – Novem Linguae ( talk) 01:28, 17 May 2024 (UTC)
In Limitations section, there is a long paragraph that seems to add little or no value to the actual limitations. It cites a single reference multiple times, but the actual content seems more about the company's failure than it is about actual WebAssembly. The example certainly isn't applicable as a broad limitation.
I suggest removing it all together. 129.78.56.157 ( talk) 03:35, 21 June 2024 (UTC)
In the WASI section.
It cites an InfoQ article, but the quoted content is actually just a promotional quote from the Wasmer CEO.
Does this belong in the article? Maybe a more neutral link in an "implementations" section would be more appropriate? 49.185.206.227 ( talk) 02:42, 25 June 2024 (UTC)