According to Mozilla : "There are future plans to allow WebAssembly to call Web APIs directly.".

https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...

Although I couldn't actually find any description of the intended capabilities.

MDN has a page for that as well:

https://developer.mozilla.org/kab/docs/Web/API

The page DOM is not listed there. The closet thing is DOMParser which will allow parsing of an XML/HTML island into a new DOM object.

https://developer.mozilla.org/kab/docs/Web/API/DOMParser

What you're missing is https://github.com/WebAssembly/host-bindings/blob/master/pro...

I believe you are over thinking this bullet point:

> Ergonomics - Allow WebAssembly modules to create, pass around, call, and manipulate JavaScript + DOM objects

That would allow WASM functionality similar to behavior already present in the browser, but that page does not say where that behavior will occur. Given this is an update to WASM it will likely occur against WASM artifacts. An example would be allowing a WASM application instance to create JavaScript event bindings and DOM artifacts on an internal DOM tree.

It is wishful thinking that an update to WASM would modify the web environment outside of WASM.

I think I’m just really confused as to what you’re saying. In the browser, you will be able to manipulate the browser DOM directly from wasm. That’s all I’m saying. I don’t think I understand what you mean in this reply.

So currently there is demand for a DOM interface in WASM and WASM has none. I have seen several WASM applications that ship markup and then fabricate their own DOM-like instance to accompany that markup to allow web-like behaviors to the WASM application instance. That is a significant amount of overhead. If WASM had access to a DOM interface applications could be written in any language that execute DOM methods on accompanying markup without need for JavaScript. You get the benefits of a self-contained event-driven UI environment with minimal overhead and without need for JavaScript, but just because WASM ships with support for DOM method execution does not necessarily mean that execution reflects a state or environment outside the WASM sandbox.

Yeah, that does sound like a lot of overhead.

> just because...

It certainly will though, 100%. I know this from talking to all sorts of people who work on wasm. That’s what the above proposal I linked you to does.

> A DOM interop spec is underway, which will allow access into the WASM target from JavaScript. It will not allow access from WASM to the DOM, because that is insecure.

More insecure than allowing arbitrary JS like we do now? I wouldn’t be surprised if we do get a WASM DOM API, maybe it won’t start as an official spec, but it’ll eventually happen.

a DOM API for wasm is planned, but IIRC before that people need to standardize the whole concept of external references/GC, so it might be still quite far away.