I don't get it why you need direct DOM access. Just wrap it in JS calls.
It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.
Just to be clear: It slows down the overhead of a function call by 50%. It doesn't slow down the function implementation which takes a very large percentage of the time.
I'm pretty sure you'll will still need a JS shim to talk to most web APIs. For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header (similar to the old 'use asm' for asm.js) as shim, but the JS shim is still there. The component model can marshal 'record types' between different WASM modules, but AFAIK not between a WASM module and a web API.
> For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header
As per the article, that's temporary until Component Model 1.0 is implemented natively in the browser. In the meantime, jco can be used:
> The groundwork for browser implementations is being laid today: jco’s transpile command already converts any component into equivalent core Wasm and JavaScript glue, making components runnable in any browser without native support.
That's no longer needed once native support is there.
One could write a js-less DOM impl I think.. neither Chrome nor Firefox itself is written in js unlike big parts of Linux that are indeed written in C. Explorer shipped with vbscript as a language that can manipulate the DOM.
The really big issue in this case is network effect, which is why I hope something can come out from the momentum building behind WASM.
One couldn't, because you'd need to standardize a JS-less DOM, which requires one to persuade Apple, Google, Microsoft, and Mozilla to agree on a new standard for a JS-less DOM API.
The DOM API is currently defined as a JS API, including JS strings, JS objects + properties, JS Exceptions, JS Promises, JS garbage collection, and on and on and on.
The effort to get all the browsers to agree to standardize a new JS-less DOM API would take years; none of the browser vendors even want to begin that conversation today.
The issue is that many modern DOM APIs assume js semantics and types (eg promises, iterables, etc) so you need to "reimplement" some js semanthic in wasm; sorta like how apple added a few custom instructions on the M1 chip specifically for the type of floating point operation required by js.
