I'd really like browser vendors exposing to wasm a graphics api, input and accessibility. So we can skip the dom and start making actual apps
WASM 3.0 Completed
341–350 of 520 posts
Re: WASM 3.0 Completed
#342When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?
Basically never, because it would require re-standardizing the DOM with a lower-level API. That would take years, and no major browser implementor is interested in starting down that road. https://danfabulich.medium.com/webassembly-wont-get-direct-d...
Killing JavaScript was never the point of WASM. WASM is for CPU-intensive pure functions, like video decoding.
Some people wrongly thought that WASM was trying to kill JS, but nobody working on standardizing WASM in browsers believed in that goal.
Re: WASM 3.0 Completed
#343Earlier quoted context omitted.
> ... document browser ... document reader ... I'm going to assume you're being sincere. But even the crustiest among us can recognize that the modern purpose for web browsers is not (merely) documents. Chances are, many folks on HN in the last month have booked tickets for a flight or bought a home or a car or watched a cat video using the "document browser". > If we think we need a more thoroughly virtualized machi…
We have, but not by choice, I miss my native apps, even though ChromeOS Platform pays the bills.
> booked tickets for a flight or bought a home or a car or watched a cat video
Would you install a native app to book a flight? One for each company? Download updates for them every now and then, uninstall them when you run out of disk space etc
I can ask the same question about every other activity we do in these non-native apps.
Re: WASM 3.0 Completed
#344Folks here might be interested in WebAssembly from the Ground Up (https://wasmgroundup.com) — an online book to learn Wasm by building a simple compiler in JavaScript. (Disclaimer: I'm one of the authors.)
So far the book only covers WebAssembly 1.0 though. We'll likely publish an update to cover the (few) new features in 2.0, but WebAssembly 3.0 is a pretty big update. Garbage collection and typed references especially add quite a lot to the spec. But, they also make a lot more things possible, which is great.
The spec itself is also very readable and accessible. Everything in the spec that's described formally is also described in plain language. I can't think of any other spec that's quite as nice to read.
Re: WASM 3.0 Completed
#345> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of stru…
I'm not familiar with WASM. Can someone explain why this is a good thing? How does this work with languages that do not have a garbage collector, like Rust?
Re: WASM 3.0 Completed
#346Earlier quoted context omitted.
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.
Webgl can't access the dom either
That's opengl on the web, a graphic api, you can't compare the two
Re: WASM 3.0 Completed
#347When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?
GC was required part, because it was needed to allow interaction between DOM-side lifetimes and WASM-side lifetimes. You might still need a puny shim to essentially "declare" whatever form you want the DOM API to look like on WASM side (probably utilizing components and WIT in the future) but that shim won't have to do anything other than register the APIs because WASM will be able to take a reference to DOM object and vice versa instead of throwing a copy of data over the wall as it is now.
Re: WASM 3.0 Completed
#348Re: WASM 3.0 Completed
#349> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of stru…
I'm not familiar with WASM. Can someone explain why this is a good thing? How does this work with languages that do not have a garbage collector, like Rust?
I works very well, thank you for asking: https://rustwasm.github.io/book/
Re: WASM 3.0 Completed
#350Earlier 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…
> WebAudio is a frigging clusterf*ck
Out of curiosity, what issues do people have with WebAudio since audio worklets became widely supported?