So my estimate is that this is going to happen approximately never. The challenges to offering a direct DOM api are numerous. The DOM API uses the full complem

So my estimate is that this is going to happen approximately never. The challenges to offering a direct DOM api are numerous. The DOM API uses the full complement of javascript types; whereas WebAssembly only has integers. So you need to either standardize a binary representation of javascript objects, arrays, functions, pointers, etc., or you need to modify all the hundreds of API calls to use different semantics, e.g. a C-style string for a node name, a wasm function-table index for a callback. References of all kinds would be a huge sticking point, especially with garbage collection involved. If you store them c-style as integers, then how do you dereference them safely, or what if you add 50 to a reference etc. If they're stored as opaque references then that's an entire new system added on to wasm. All of this could be done in theory, but I don't see it happening with WebAssembly. WebAssembly is a deliberately conservative and simple project. It was partly a reaction to the more aggressive NaCl project which had threads and its own low-level API pepper etc. WebAssembly is moving at the glacial pace typical of browser consensus, and the stakeholders involved don't actually want it to take over the web ecosystem (Apple doesn't want web apps to be as good as App Store apps; Google doesn't want opaque web apps that can't be easily injected with ads and analytics; Mozilla doesn't want the browser to be a simple, commodity VM).