Even then, there's tons of logic you want to execute in the browser that aren't related to UI. For example, any sort of number crunching. That stuff is now feasible, which opens up all kinds of applications.
This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game.
Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games.
But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you:
This can be easily achieved by buffering calls to the DOM and merging batches of actions together (you could probably even divide DOM actions into priority queues to improve reaction time at expense of throughput in less important UI elements)
But I don't think languages will interact with the DOM extensively once it has been properly abstracted.
One major difficulty would be to have it available quickly so a page refresh doesn't take until the WASM binary has sorted out it's internal state.
Not really. You're still hamstrung by either being single threaded & time sliced with the UI thread (huzzah for cooperative multitasking still somehow not being dead), or you need to jump through the webworkers hoop if you're lucky enough to have a problem & dataset that's compatible with webworker's rather severe limitations.
webasm claims to have threading support on the roadmap but until that happens anything truly involving heavy number crunching is still largely infeasible. And with SharedArrayBuffer being killed by spectre there's a lot of rather major unknowns to deal with.