Nobody from the WASM working group is working on that though, so the probability of direct access to the page’s DOM is close to zero. Programmers have been hoping for this for years but WASM has been very clear that isn’t in the project’s design path. The are intentional design objectives limiting that work officially but likely the largest hurdle is overcoming various security and privacy concerns already in place due to the isolation of WASM instances from their containing page.

Far more likely, and this already exists in various unofficial examples, is that WASM instances ship with a DOM for accessing markup provided by or requested into the WASM instance.

> ... WASM instances ship with a DOM for accessing markup provided by or requested into the WASM instance.

Sounds like it would achieve the same end goal? eg direct access to the page elements, without needing to go through JS

Or is that my not really understanding the problem space? :)

No, a DOM that is provided by a WASM instance will provide access to markup contents available to that WASM instance, such as markup requested or shipping with the WASM code, but not outside the WASM instance such as the containing page.

Interesting. What's the intended use case for that?

Trying to think of something, but nothing is coming to mind.

If your WASM application makes use of any kind of XML or HTML content you need to parse it or it’s just a string.

No worries, thanks. :)

Check Qt, Blazor or Uno.

Thanks, but Qt isn't really suitable for web apps. :(

eg PgAdmin, which went from a good desktop application (v3) to unusable in non-trivial cases on the desktop when they switched to Qt (web). :(

Blazor / Uno seem to be C#? Not (personally) going to touch that with a long stick. ;)