I predict WASM is going to thrive and spread as a generic way of running complex plugins safely inside another piece of software.

Desktop apps (SDL et al) don't interact with DOM but they thrive. I don't agree with this take at all. I do however think WebAssembly implementations need to increase storage size, with the current 10MB localStorage in Firefox/Chrome and 5MB in Opera et al, web apps are almost completely memoryless without cloud. If you could use a web app as a standalone app with its own memory that you can download/upload/sync it'd be much more useful.

This is a take I don't actually agree with, on it's face, but I will say that even if we assume it's true that DOM access limitations are causing stagnation, I think most devs would prefer wasm to make the DOM unnecessary, rather than to couple anything tighter.

The DOM is kind of great for modeling documents, and quickly creating a form. As far as event driven design goes, it's very performant and accessible. But if you want to do anything that isn't vector graphics or form design, the entire browser stack can hold you back in varying ways.

Personally, I'm seeing a lot of potential in the wasm vector libraries, but I'm even more excited about shader-based, immediate mode guis. And honestly, the fact that you don't need a browser is a bonus, but definitely not the main selling point.

Your milage may vary, of course, but I'm very optimistic about what's coming with wasm!

I see a lot of work around WASM lately with WASI and there are a lot of interesting implementations one example is wasi-cloud-core[1] it could open the doors for more services like wasmcloud.com.

[1] https://github.com/WebAssembly/wasi-cloud-core

Host object (such as DOM elements) support has been underway for a long long long long time. Component-model has been making ongoing progress towards this goal. It'll eventually happen.