No. Also because it's nearly impossible, has only downsides including worse performance.
How could WebAssembly offer a single API to different languages with different internal datastructures and calling conventions and different memory allocators and garbage collectors?
They would have to pick a weakest/most-low-level common denominator, like the C calling convention.
If say the language you are compiling to WebAssembly is Haskell, Ruby or Go .. you will still need to bindings that are going to feel as 'calling into another language with non native (to this language) datastructures'.
And they will have to be implemented for each language that targets WebAssembly. And kept up to date.
If this calling out happens with typical C datastructures and calling conventions, you would need a complete reimplemention of the DOM, including meetings about every detail of the new API surface since in this world something as simple as a getting the boundingbox would not be easily expressible.
Also: since it's unclear who manages (owns) these datastructures and how, it means that most implementations will just always copy the data over.
So you have worse performance, double the attack surface, even worse performance because now the DOM needs to run in the same sandbox for it to be safe. And I'm not even sure all security policies can be implemented at all, even then. What about the rule that only code triggered by a click may open a new window? Is that even something we can implement on the WebAssembly level? No.
And after we finally all agree on what the API surface should be, you'll need at least 2 to 3 years to get a first implementation. Since the only way for browser vendors to do this is to implement their DOM completely for scratch.
And while we are doing that we also have to keep the feature set in sync, and maintain the current DOM because JavaScript isn't going anywhere.. and what if you want to use both?
The notion that WebAssembly could or should itself support bindings other than 'call JavaScript and interact with the DOM from there' is quite delusional and hints at a fundamental misunderstanding of how programming languages are actually implemented and what WebAssembly actually is.
Nope. It's because one of the things that WebAssembly did to succeed was stay small. Instead of a huge kitchen sink spec, it's lean and mean, and will add things over time. DOM access is one of the first features to be layered on.
Not as far as I'm aware. WASM is still sandboxed like JS is. I believe DOM access is coming, and in the meantime I believe you can still use <canvas> directly.
