WasmGC is now available, so I guess it can also be solved sometime in the future, and I wouldn’t mind it at all.
Though we would need much better wasm debug tooling, similarly to JS consoles — today’s minified, obfuscated JS is not much better than machine code, but at least with the tooling we can sort of touch into the internals. I would like to keep that property of the web.
> I assume browsers will one day expose a native DOM API.
TBH, that's extremely unlikely to happen. The entire DOM is built around the Javascript object model, trying to map the DOM to a C-style API would be possible, but inconvient to use and performance-wise it really wouldn't make a difference compared to going through a JS shim (since performance will be dominated by the browser-intenal DOM implementation, not by the user code manipulating it).
A 'WASM-native' WebGPU API would make a lot more sense, but again, that's extremely unlikely to happen.
The currently required Javascript shim might still disappear, but only because it might be generated automatically under the hood in the future.
> WASM can only access it through JS, foregoing its benefits
Is this a fundamental limitation of WASM? I assume browsers will one day expose a native DOM API.