Earlier quoted context omitted.
There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.
That is just FUD. It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure. Unity WebAssembly games are just a few hundred KB. Who cares about DOM, WebGL takes care of the UI part.
If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just leave.
Unity complex with basically zero runtime and uses webgl so it doesn't need to include that either (just the actual game itself).
People use the Dom because it's standard, doesn't have to be downloaded every time, and offers tons of features.
Nobody is going to write directly to webgl for a standard website (That's easily 9,999 out of 10,000 sites). That means you have to do something like drag Qt or GTK everywhere which takes even more time to download and parse.
Your idea seems to be: download and parse a bloated runtime, download and parse a huge display library set, download and parse the misc shim pieces, and then download and parse your app. This is all done with the hope that your crud app that spends most of it's time doing nothing will be a fraction faster and you can write it in something that isn't JS.
Not a great plan.