> 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.
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.
Anyway I am quite sure that you could almost completely get rid of js glue code by importing the static Reflect methods and a few functions like (a,b)=>a+b for the various operators, add a single array/object References to hold refs and you can do pretty much everything from wasm by mixing imported calls
...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.
https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
The only thing that might be expensive is translating string data from the language-specific string representation on the WASM heap into the JS string objects expected by the DOM API. But this same problem would need to be solved in a language-portable way for any native WASM-DOM-API, because WASM has no concept of a 'string' and languages have different opinions about what a string looks like in memory.
But even then, the DOM is an inherently slow API starting with the string-heavy API design, the bit of overhead in the JS shim won't suddenly turn the DOM into a lightweight and fast rendering system.
E.g. it's a bit absurd to talk about performance and the DOM in the same sentence IMHO ;)
_Telling the browser how you want the DOM manipulated_ isn't the expensive part. You can do this just fine with Javascript. The browser _actually redrawing after applying the DOM changes_ is the expensive part and won't be any cheaper if the signal originated from WASM.