I have been following very closely the roadmap for webassembly, specially the performance hit of calling JS interop. As part of this reference types proposal we are going to be able to have basic manipulation of tables inside Wasm. Phase 4 has been approved June 23rd meeting. Firefox and Chrome are working on the implementation of this proposal WebAssembly roadmap. Chromium implementation. Based on this answer Wasm access dom. and quoting chromium description
Allow WebAssembly modules to hold references to JS/DOM objects, passing them as arguments, storing them in locals and globals, and storing them in WebAssembly.Table objects.
Is this going to allow accessing the DOM from wasm? or there are further implementations required? Will improve/match JS performance accessing the DOM? Will this allow to have a virtual DOM in wasm and make only necessary changes in the real DOM? @Andreas Rossberg?
Adding this response from Andreas Rossberg Explain the conection of GC and DOM-Access
However, the new proposal for reference types that we split off from the GC proposal tries to give a more nuanced answer to that. It introduces reference types without any functionality for allocating anything within Wasm itself. In an embedding where host references are garbage-collected that still requires a Wasm implementation to understand GC. But in other embeddings it does not need to.
Edit for completeness webassembly-interface-types
A module can store references to DOM objects (or whatever the respective host environment provides) in Wasm, but to access them, it needs to import respective functionality. That will not change. Wasm is a virtual instruction set, not an API. And it is not Web-specific.
But of course, you could now implement a rich library in Wasm, such as a shadow DOM or virtual DOM, that does most of the work in Wasm and only calls out to the real DOM where needed.