5 ms·

Still no mention of DOM. <sets alarm for three years from now> See you all for WASM 4.0.

0xfffafaCrash 1y ago
https://danfabulich.medium.com/webassembly-wont-get-direct-dom-support-any-time-soon-a3e0ea04c688 https://danfabulich.medium.com/webassembly-wont-get-direct-d...
Imustaskforhelp 1y ago
I wish the same mate, Please wasm team, I am more than happy waiting 3 years if you can guarantee that you are looking into the best way possible into integrating this feature of dom manipulation. I sometimes feel like js is too magic-y, I want plain boring golang and want to write some dom functions without using htmx preferably. Please give us more freedom! This might be the most requested feature and this was how I came across knowing wasm in the first place (leptos video from some youtuber I think, sorry if i forgot)
- hinkley 1y ago
  I was even trying to be charitable and read the feature list for elements that would thin down a third party DOM access layer, but other than the string changes I’m just not seeing it. That’s not enough forward progress. WASM is just an extremely expensive toy for browsers until it supports DOM access.
  - flohofwoe 1y ago
    It's a chicken egg situation. The people already using WASM either don't care about the DOM or had realized long ago that going through a JS shim works just as well, the rest just complain time and time again that WASM has no DOM access whenever there's a HN thread about WASM, but usually don't even use WASM for anything.
    - lyu07282 1y ago
      Especially if there was major momentum of people writing their web applications with wasm, there would be a reason to eventually get that massive undertaking of creating the ABI for that working. Then all those applications could just recompile to make use of this new hypothetically faster API. The bigger issue here is that it just doesn't make any sense to write frontend code in rust or go or whatever in the first place. The whole js ecosystem evolved to become a damn good environment to write UIs with, people don't know the massive complexity this environment evolved to solve over decades.
      - hinkley 1y ago
        I feel like this is asking for a jquery for WASM. All you need are css selectors and verbs. The selector is a choke point that keeps you from having to create a concrete object on both sides of the FFI. And the fact that jquery is built for bulk operations would also be a feature you’d want to preserve for performance reasons.
  - samsartor 1y ago
    My old team shipped a web port of our 3D modeling software back in 2017. The entire engine is the same as the desktop app, written in C++, and compiled to wasm. Wasm is not now and will never be a magic "press here to replace JS with a new language" button. But it works really well for bringing systems software into a web environment.
  - afiori 1y ago
    The three main camps of wasm use cases are ( in no particular order ) 1. Non browser application (lightweight cloud, plugins, sandboxing) 2. Performance kernels (like compiling a game/rendering engine or AI stuff) 3. Compiling js-like applications from other languages (eg blazor wasm and others) The only case where DOM access would be useful is 3 and even there 90% of the gains are already available from the JS-strings proposal to avoid copying+reencoding. Direct DOM access is otherwise mostly a red herring
cdata 1y ago
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.
- pier25 1y ago
  Yep and with better raw DOM performance than React: https://leptos.dev/ https://leptos.dev/ https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- catapart 1y ago
  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.
  - nicoburns 1y ago
    https://github.com/wasm-bindgen/wasm-bindgen https://github.com/wasm-bindgen/wasm-bindgen is the tool for raw access to the DOM APIs.
    - catapart 1y ago
      Ah, yes! This seems like exactly the kind of minimalist exposure I was trying to find, to avoid the emscripten dependency. Thanks!
flohofwoe 1y ago
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 the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too. Just make sure that the JS code has enough 'meat', e.g. don't call accross the WASM/JS boundary for every single DOM method call or property change. While the call itself is fast, the string conversion from the source language specific string representation on the WASM heap into JS strings and back is not free (getting rid of this string marshalling would be the only theoretical advantage of a 'native' WASM DOM API).
- serial_dev 1y ago
  > Direct DOM access doesn't make any sense as a WASM feature. …proceeds to explain why it does make sense…
  - flohofwoe 1y ago
    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.
    - dustingetz 1y ago
      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)
spankalee 1y ago
DOM wouldn't be part of WASM, it'd be part of the host. If there ever is a WASM-native DOM API, WASM GC should help a lot with that.
whizzter 1y ago
It's explicitly negated from the Wasm-GC spec, too damn much security issue surface that keeps all of the browser makers solidly in the "do not want to touch" camp.
davexunit 1y ago
Wasm doesn't specify any I/O facilities at all. DOM is no different. There's a strict host/guest boundary and anything interacting with the outside world enters Wasm through an import granted by the host. On the web, the host is the JS runtime.
mikewarot 1y ago
If you give WASM access to everything, you've defeated the main reason it exists. Ambient authority is the reason we need WASM in the first place.
- afiori 1y ago
  For server applications true, but the reason browsers made wasm was because they needed a safer/portable/standardizable alternative to PNaCl
sjrd 1y ago
Wasm 3.0, with its GC and exception support, contains everything you need. The rest is up to the source language to deal with. For example, in Scala.js [1], which is mentioned in the article, you can use the full extent of JavaScript interop to call DOM methods right from inside your Scala code. The compiler does the rest, transparently bridging what needs to be. [1] https://www.scala-js.org/doc/project/webassembly.html https://www.scala-js.org/doc/project/webassembly.html
someuser345 1y ago
End-users DON'T want developers' apps running in the browser to have freedom to access everything on the end-users' machines. Not having direct dom access is a security feature, as much as an MMU is. Please don't ask for this.
- afiori 1y ago
  Wasm is sandboxed at pretty much the same security boundary as js there is nothing a DOM-enabled wasm module could do (security/privacy wise) that JavaScript can't already do
  - hinkley 1y ago
    Except avoid supply chain attacks by not having the shittiest package management system in the current era.

https://danfabulich.medium.com/webassembly-wont-get-direct-dom-support-any-time-soon-a3e0ea04c688 https://danfabulich.medium.com/webassembly-wont-get-direct-d...

Imustaskforhelp 1y ago

I wish the same mate, Please wasm team, I am more than happy waiting 3 years if you can guarantee that you are looking into the best way possible into integrating this feature of dom manipulation. I sometimes feel like js is too magic-y, I want plain boring golang and want to write some dom functions without using htmx preferably. Please give us more freedom! This might be the most requested feature and this was how I came across knowing wasm in the first place (leptos video from some youtuber I think, sorry if i forgot)

hinkley 1y ago
I was even trying to be charitable and read the feature list for elements that would thin down a third party DOM access layer, but other than the string changes I’m just not seeing it. That’s not enough forward progress. WASM is just an extremely expensive toy for browsers until it supports DOM access.
- flohofwoe 1y ago
  It's a chicken egg situation. The people already using WASM either don't care about the DOM or had realized long ago that going through a JS shim works just as well, the rest just complain time and time again that WASM has no DOM access whenever there's a HN thread about WASM, but usually don't even use WASM for anything.
  - lyu07282 1y ago
    Especially if there was major momentum of people writing their web applications with wasm, there would be a reason to eventually get that massive undertaking of creating the ABI for that working. Then all those applications could just recompile to make use of this new hypothetically faster API. The bigger issue here is that it just doesn't make any sense to write frontend code in rust or go or whatever in the first place. The whole js ecosystem evolved to become a damn good environment to write UIs with, people don't know the massive complexity this environment evolved to solve over decades.
    - hinkley 1y ago
      I feel like this is asking for a jquery for WASM. All you need are css selectors and verbs. The selector is a choke point that keeps you from having to create a concrete object on both sides of the FFI. And the fact that jquery is built for bulk operations would also be a feature you’d want to preserve for performance reasons.
- samsartor 1y ago
  My old team shipped a web port of our 3D modeling software back in 2017. The entire engine is the same as the desktop app, written in C++, and compiled to wasm. Wasm is not now and will never be a magic "press here to replace JS with a new language" button. But it works really well for bringing systems software into a web environment.
- afiori 1y ago
  The three main camps of wasm use cases are ( in no particular order ) 1. Non browser application (lightweight cloud, plugins, sandboxing) 2. Performance kernels (like compiling a game/rendering engine or AI stuff) 3. Compiling js-like applications from other languages (eg blazor wasm and others) The only case where DOM access would be useful is 3 and even there 90% of the gains are already available from the JS-strings proposal to avoid copying+reencoding. Direct DOM access is otherwise mostly a red herring

cdata 1y ago

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.

pier25 1y ago
Yep and with better raw DOM performance than React: https://leptos.dev/ https://leptos.dev/ https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
catapart 1y ago
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.
- nicoburns 1y ago
  https://github.com/wasm-bindgen/wasm-bindgen https://github.com/wasm-bindgen/wasm-bindgen is the tool for raw access to the DOM APIs.
  - catapart 1y ago
    Ah, yes! This seems like exactly the kind of minimalist exposure I was trying to find, to avoid the emscripten dependency. Thanks!

flohofwoe 1y ago

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 the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too. Just make sure that the JS code has enough 'meat', e.g. don't call accross the WASM/JS boundary for every single DOM method call or property change. While the call itself is fast, the string conversion from the source language specific string representation on the WASM heap into JS strings and back is not free (getting rid of this string marshalling would be the only theoretical advantage of a 'native' WASM DOM API).

serial_dev 1y ago
> Direct DOM access doesn't make any sense as a WASM feature. …proceeds to explain why it does make sense…
- flohofwoe 1y ago
  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.
  - dustingetz 1y ago
    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)

spankalee 1y ago

DOM wouldn't be part of WASM, it'd be part of the host. If there ever is a WASM-native DOM API, WASM GC should help a lot with that.

whizzter 1y ago

It's explicitly negated from the Wasm-GC spec, too damn much security issue surface that keeps all of the browser makers solidly in the "do not want to touch" camp.

davexunit 1y ago

Wasm doesn't specify any I/O facilities at all. DOM is no different. There's a strict host/guest boundary and anything interacting with the outside world enters Wasm through an import granted by the host. On the web, the host is the JS runtime.

mikewarot 1y ago

If you give WASM access to everything, you've defeated the main reason it exists. Ambient authority is the reason we need WASM in the first place.

afiori 1y ago
For server applications true, but the reason browsers made wasm was because they needed a safer/portable/standardizable alternative to PNaCl

sjrd 1y ago

Wasm 3.0, with its GC and exception support, contains everything you need. The rest is up to the source language to deal with. For example, in Scala.js [1], which is mentioned in the article, you can use the full extent of JavaScript interop to call DOM methods right from inside your Scala code. The compiler does the rest, transparently bridging what needs to be. [1] https://www.scala-js.org/doc/project/webassembly.html https://www.scala-js.org/doc/project/webassembly.html

someuser345 1y ago

End-users DON'T want developers' apps running in the browser to have freedom to access everything on the end-users' machines. Not having direct dom access is a security feature, as much as an MMU is. Please don't ask for this.

afiori 1y ago
Wasm is sandboxed at pretty much the same security boundary as js there is nothing a DOM-enabled wasm module could do (security/privacy wise) that JavaScript can't already do
- hinkley 1y ago
  Except avoid supply chain attacks by not having the shittiest package management system in the current era.