Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.

There isn't the political will-power to make it happen and force all the browser vendors to agree and implement. Hence status-quo remains.

Which is ironic as the DOM interface was designed as an abstract interface (the IDL used in the spec is more interested in compatibility with Java than JS).

In practice though the main reason is that to have decent DOM bindings you need to stabilize many other specs first (unless you do a ultra-specific DOM-only extension, but nobody wants that)

WASM can access the DOM by its foreign functions interface. It still needs some data conversion, but it's not through JS.

Rust, for example, has a huge package with interfaces for every DOM function.

I have been very successful in replacing a JS browser application with Rust. It has been great, because Rust is much easier to change, and since the application is complex, I need to change it a lot.

But I wouldn't recommend it in general, because JS (and for slightly more complex things, TS) is much easier to create because of all the old Rust features that surface every time you mention it. And most GUI code is simple enough that you only have to write once, maybe fix a few details, and forget about it.

Wasm would be much more compelling if it was target by higher level languages.

I am waiting to be able to run the JVM and have client side swing again in WASM

Why waiting when it is already available?