Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM 3.0 Completed

webassembly.org

Post reply on HN
Print view View original

81–90 of 520 posts

Re: WASM 3.0 Completed

#81

Post by dcchambers »

flohofwoe wrote: post #63
hinkley wrote: post #35

Still no mention of DOM. See you all for WASM 4.0.

That old thing again ;) Direct DOM access doesn't make any sense as a WASM feature. It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory). If you need to manipulate th…

> Direct DOM access doesn't make any sense as a WASM feature.

I disagree. The idea of doing DOM manipulation in a language that is not Javascript was *the main reason* I was ever excited about WASM.

Re: WASM 3.0 Completed

#82

Post by flohofwoe »

serial_dev wrote: post #76
flohofwoe wrote: post #63

Earlier quoted context omitted.

That old thing again ;) Direct DOM access doesn't make any sense as a WASM feature. It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory). If you need to manipulate th…

> Direct DOM access doesn't make any sense as a WASM feature. …proceeds to explain why it does make sense…

It's not a WASM feature, but would be a web browser feature outside the WASM standard.

E.g. the "DOM peeps" would need to make it happen, not the "WASM peeps".

But that would be a massive undertaking for minimal benefit. There's much lower hanging fruit in the web-API world to fix (like for instance finally building a proper audio streaming API, because WebAudio is a frigging clusterf*ck, and if any web API would benefit from an even minimal reduction of JS WASM marshalling overhead it would be WebGL2 and WebGPU, not the DOM. But even for WebGL2 and WebGPU the cost inside the browser implementation of those APIs is much higher than the WASM JS marshalling overhead.

Re: WASM 3.0 Completed

#83

Post by themerone »

diego_moita wrote: post #48

There's a joke in Brazil saying "Brazil is the country of the future and will always be that. It will never be the country of the present". WASM is and will always be the greatest technology of the future. It will never be the greatest technology of the present.

Wasm is one of the best solutions for running untrusted code. Alternative are more complicated or have limited language choices.

Re: WASM 3.0 Completed

#84

Post by cjs_ac »

flohofwoe wrote: post #63
hinkley wrote: post #35

Still no mention of DOM. See you all for WASM 4.0.

That old thing again ;) Direct DOM access doesn't make any sense as a WASM feature. It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory). If you need to manipulate th…

WASM is an abbreviation for WebAssembly. If it doesn't have DOM access, WebAssembly is as related to the Web as JavaScript is to Java. A language ecosystem with no I/O capability is as much use as a one-legged man at an arse-kicking party.

Re: WASM 3.0 Completed

#85

Post by flohofwoe »

dcchambers wrote: post #81
flohofwoe wrote: post #63

Earlier quoted context omitted.

That old thing again ;) Direct DOM access doesn't make any sense as a WASM feature. It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory). If you need to manipulate th…

> Direct DOM access doesn't make any sense as a WASM feature. I disagree. The idea of doing DOM manipulation in a language that is not Javascript was *the main reason* I was ever excited about WASM.

> The idea of doing DOM manipulation in a language that is not Javascript

...is already possible, see for instance:

https://rustwasm.github.io/docs/wasm-bindgen/examples/dom.ht...

You don't need to write Javascript to access the DOM. Such bindings still call JS under the hood of course to access the DOM API, but that's an implementation detail which isn't really important for the library user.

Re: WASM 3.0 Completed

#86

Post by catapart »

cdata wrote: post #61
hinkley wrote: post #35

Still no mention of DOM. See you all for WASM 4.0.

Don't sleep on the Rust toolchain for this! You can have DOM-via-Wasm today, the tools generate all the glue for you and the overhead isn't that bad, either.

Got a rec? The reply to you is talking about a component framework, rather than actual vanilla html/css access. I haven't seen anything, personally, that allows real-time, direct DOM interaction.

Re: WASM 3.0 Completed

#87

Post by whizzter »

preommr wrote: post #22

On gc: > Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm. There's already a lot misunderstandings about wasm, and I fear that people will just go "It supports GC, so we can just export python/java/c#/go etc." This is not a silver b…

Wasm-GC are abstractions for compiler writers to enable GC dependent languages to run without shipping a GC to run inside the already GC'd browser/Wasm heap and instead just use the browser GC directly.

So yes, Java,C#,etc will work better (If you look at the horrible mess the current C# WASM export generates it basically ships with an inner platform containing a GC), and no, it will explicitly not speak with "javascript" objects (you can keep references to JS objects, but you cannot call JS methods directly).

Re: WASM 3.0 Completed

#88

Post by em-bee »

davey48016 wrote: post #47
onionisafruit wrote: post #31

Earlier quoted context omitted.

I will be interested to see if Go is able to make use of this GC and if so, how much that wasm binaries

https://github.com/golang/go/issues/63904 Skimming this issue, it seems like they weren't expecting to be able to use this GC. I know C# couldn't either, at least based on an earlier state of the proposal.

this thread confirms my suspicions. some languages may benefit from a built in GC, but those languages probably use a generic GC to begin with. wheras any language that has a highly optimized GC for their own needs won't be able to use this one.

Re: WASM 3.0 Completed

#89

Post by flohofwoe »

whizzter wrote: post #78
flohofwoe wrote: post #33

Since it hasn't been mentioned here yet: I wonder if the multiple-memories feature will somehow allow to avoid the extra copy that's currently needed when mapping a WebGPU resource. This mapping is available in a separate ArrayBuffer object which isn't accessible from WASM without calling into JS and then copying from the ArrayBuffer into the WASM heap and back. Multiple WASM memories and Clang's/LLVM's address space…

I'm just getting horrible segmenting and far-pointer vibes of the whole thing, been coding a classic Gameboy game for fun so fiddling with memory mappings is part of the "fun" but for anything non-constrained I'd hate that. We buried far pointers with DOS and Win16 for a good reason..

I'd take segment-pointers over copying megabytes of memory around anyday though ;)

It's not much different than dealing with all the alignment rules that are needed when arranging data for the GPU.

Re: WASM 3.0 Completed

#90

Post by Jtsummers »

quix0t3 wrote: post #71

steve job's ghost will prevent wasm adoption.

> steve job's ghost will prevent wasm adoption.

https://webassembly.org/features/

That isn't updated for Safari 26, but by that table Safari 18 is only missing 3 standardized features that Chrome supports, with a fourth that is disabled by default. So what's the point of your comment? Just to make noise and express your ignorance?

Post reply on HN