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

101–110 of 520 posts

Re: WASM 3.0 Completed

#101

Post by cosmic_cheese »

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…

Isn’t the whole reason why people want DOM access is so that the JavaScript side doesn’t have any meat to it and they can write their entire web app in Rust/Go/Swift/etc compiled to webasm without performance concerns?

Re: WASM 3.0 Completed

#102

Post by mdhb »

flohofwoe wrote: post #85
dcchambers wrote: post #81

Earlier quoted context omitted.

> 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.

Dart also has this and as you can see in the examples in the README the APIs look exactly the same as what you are used to in JavaScript but now are fully typed and your code compiles to WASM.

https://github.com/dart-lang/web

Re: WASM 3.0 Completed

#103

Post by dcchambers »

flohofwoe wrote: post #85
dcchambers wrote: post #81

Earlier quoted context omitted.

> 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.

While technically possible - the calls to javascript slow things down and you're never going to get the performance of just writing javascript in the first place, much less the performance of skipping javascript altogether.

Re: WASM 3.0 Completed

#104

Post by jsheard »

renehsz wrote: post #97
jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn't necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time). But if you really need more than 4GB of memory, then sure, go ahead and use it.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

Re: WASM 3.0 Completed

#105

Post by mdhb »

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…

This isn’t true at all in Dart for example which is a WASM-GC language. Literally one of the very main selling points of Dart is you write your code once and it runs anywhere, WASM is just another compile target like x64 or RISC-V or iOS.

Re: WASM 3.0 Completed

#106

Post by titzer »

IshKebab wrote: post #96
phickey wrote: post #28

Earlier quoted context omitted.

https://github.com/WebAssembly/custom-page-sizes is a proposal championed by my colleague to add single byte granularity to Wasm page sizes, motivated by embedded systems and many other use cases where 64kb is excessive. It is implemented in wasmtime, and a Firefox implementation is in progress.

> Allow Wasm to better target resource-constrained embedded environments, including those with less than 64 KiB memory available. If it has less than 64 kB of memory how is it going to run a WASM runtime anyway? And even cheap microcontrollers tend to have more than 64 kB of memory these days. Doesn't not seem remotely worth the complexity.

> If it has less than 64 kB of memory how is it going to run a WASM runtime anyway?

There is WARDuino (https://github.com/TOPLLab/WARDuino and https://dl.acm.org/doi/10.1145/3357390.3361029).

A runtime that accepts Wasm modules that use a large fraction of the functionality, there is going to be a RAM requirement in the few KiB to few tens of KiB. There seems to be a branch or fork of Wasm3 for Arduino (https://github.com/wasm3/wasm3-arduino).

If you are willing to do, e.g. Wasm -> AVR AOT compilation, then the runtime can be quite small. That basically implies that compilation does not happen on device, but at deployment time.

Re: WASM 3.0 Completed

#107

Post by dustingetz »

flohofwoe wrote: post #82
serial_dev wrote: post #76

Earlier quoted context omitted.

> 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 ben…

so the feature does make sense, it’s just the implementation crosses a Conway’s law boundary

(I also want this feature, to drive DOM mutations from an effect system)

Re: WASM 3.0 Completed

#108

Post by davexunit »

jasonthorsness wrote: post #54

I don't think the GC in this version has the features required to enable a C# runtime on top of it yet: https://github.com/WebAssembly/gc/issues/77 I wonder what language this GC can actually be used for at this stage?

The article answers your question, there are at least 6 languages: Java, OCaml, Scala, Kotlin, Scheme, and Dart.

Re: WASM 3.0 Completed

#109

Post by stusmall »

TimTheTinker wrote: post #55
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 enables some pretty cool apps in the present, though. I think Figma heads the list.

We use it heavily here at Ditto. It's fantastic.

Re: WASM 3.0 Completed

#110

Post by titzer »

endorphine wrote: post #46

Oh no, right after I started writing a binary decoder for 2.0. Does anybody know how much this changes things as far as a decoder is concerned?

It introduces new types (structs and arrays), a new section for tags, and several dozen instructions (first-class functions, GC, tail calls, and exception handling). It generalizes to multiple memories and tables, as well as adding 64-bit memories. The binary format changes aren't too bad, but it's a fairly big semantic addition.
Post reply on HN