Because before it can access the DOM, it needs to support:

* reference types * interface types * exception handling * typed function references * garbage collection

I.e. most WASM proposals must be accepted before we can use the DOM from WASM... by the pace it's been moving forward, I guess this will take at least several years (3-4+).

https://github.com/WebAssembly/proposals

Webassembly can access anything you give it access to, and only that.

That’s great from a trust perspective because it means you can use a binary blob with confidence that it can’t do anything it isn't explicitly allowed to.

There’s no reason to specify access to the DOM for webassembly since you can grant that access from JS.

The hard bit is making it fast; ideally you could call between WASM and browser code with zero trampolines, but going via JS means you need two.

> There’s no reason to specify access to the DOM for webassembly since you can grant that access from JS.

There are reasons. If I could write web apps in a different language without having to use any JS, I would. It would be wonderful to be able to pick whatever language you want, compile it, and then deploy it. Having a JS bridge just seems like a clunky workaround that you have to live with.

> That’s great from a trust perspective because it means you can use a binary blob with confidence that it can’t do anything it isn't explicitly allowed to.

JavaScript is already sandboxed and can access only what you allow it to. Why have a sandbox within a sandbox?

> Having a JS bridge just seems like a clunky workaround that you have to live with.

It's 100 lines of code that you write once and never touch again. Not especially hard to live with VS having a fixed spec that can't evolve over time.

> JavaScript is already sandboxed and can access only what you allow it to. Why have a sandbox within a sandbox?

Javascript can access only what the user grants it access to. Within that set, WebAssembly can access only what the site author grants it access to.

There are quite a few good reasons to want nesting sandboxes. Hell, that's my favorite thing about Lua (a language I would otherwise avoid).

I'd guess, the main reason is that the standard for doing so is not fixed.

The idea seems that WASM tries to be a general compilation target, so they don't wanna mess it up by integrating with the web platform too soon.

Don't know when or if the interface types are released.

You can bridge through JavaScript. It's not a big deal in practice. WASM is still very immature. You do not want to build your whole app in WASM if you want to keep a full head of hair.

It does limit a lot of use-cases from being viable in WASM.

Anything that needs to do a lot of DOM access will probably see a big performance hit if you rewrite it in WASM because there will be too much overhead from crossing the JS-WASM border.

You can access DOM and WebAPI using em_val. Emscripten provides the support. WASM doesn't however. It's complicated.

Not sure why I'm being downvoted - the answer doesn't seem obvious?