Hacker News Reader

Comment by rafaelmn | Hacker News Reader

Did they solve GC and DOM access ? It's been years since it was "just about to happen" and I stopped paying attention in the meantime. But if it had that I agree - it would be ideal if JS was a legacy thing and a saner WASM first class language got to replace it.

Keep the single threaded event loop approach but kill the JS semantics.

View on HN

Garbage collection is solved to the extent that host garbage collection is now available via WasmGC:

https://developer.chrome.com/blog/wasmgc/

https://v8.dev/blog/wasm-gc-porting

But languages like C# want more features in WasmGC:

https://github.com/dotnet/runtime/issues/94420

No direct DOM access yet. You still have to use JavaScript glue code to get at the DOM.

The problem is that they promised that the WasmGC would include the much desired access to JavaScript objects but now this crucial aspect is no longer part of it and postponed again.

Wasm GC is shipped in stable releases of all major browsers except for Safari but that will be changing shortly if it hasn't already (my info is a few weeks old.) The important thing to note about Wasm is that all important functionality, such as access to I/O and the DOM, have to arrive in the form of host imports to a Wasm module. With this in mind, thanks to Wasm GC it is possible to do web UIs from Wasm by importing the relevant bits of the DOM API that the module needs. Projects like Hoot (Scheme) and Kotlin port are already demoing such things.

> Projects like Hoot (Scheme) and Kotlin port are already demoing such things.

And Scala.js has shipped it. [1] Although technically experimental, it has no known bugs and it has full support of things like manipulating DOM objects from Scala.js-on-Wasm code.

[1] https://www.scala-js.org/news/2024/09/28/announcing-scalajs-...

I thought the js DOM API was atrocious. But they copied it over with Java object hierarchy into Scala.js. Makes me want to give up on coding altogether.

Actually I don't want DOM access and GC for wasm. At least not yet. It overcomplicates a lot and I simply cannot imagine that a GC can be one-size-fits-all languages.

I want fixed-size buffer-backed structs for JS. Basically a DataView as a C struct. This would massively benefit interop and solve some shortcomings of DataView.

There was a proposal for a binary AST for JS several years ago [1]. Why not just use that as JS0? It's separate and can offer new possibilities as well.

[1]: https://github.com/tc39/proposal-binary-ast

Problem with AST is that it still kind of forces JS semantics which we should be working away from if we're doing this big leap.

(I was the tech lead for this proposal)

How would this be useful for a JS0?

Reply on news.ycombinator.com