The Web evolved to do incremental/progressive rendering, it's one of the best aspects. Undumping a frozen Dart heap was a goal to speed up gmail, but over long thin pipes (my "LTE", most of the time), incremental/progressive wins.
Sure, games come in big packages and good ones are worth the download time. For most other apps, small is beautiful. iOS app update still sucks, not just because semi-automatic.
Similarly, just because it'll be possible to implement a full web engine efficiently in WebAssembly doesn't mean sites will suddenly stop paying any attention to standards or accessibility.
As for adblockers, I can think of several ways to block ads in such a world, including hooking the sockets API to block or sandbox access to ad-serving hosts, or providing hot-patches that stub out common ad-serving libraries. It'll get harder, but not impossible.
(And a disaster for the companies that build them and get sued later.)
I'm saying that div-itis is possible today, but it's a bad idea, and as far as I can tell many new sites still use semantic markup when available.
Along the same lines, I would expect that even if people implement a web engine in wasm, many will still use semantic markup.
That said, I agree that people don't pay enough attention to accessibility, and should. But I don't think wasm or wasm-based rendering engines will make that worse.
If you go all-in on wasm to do "your own rendering", external software won't know where to find a "DOM" or how to understand it, unless some other kind of reinvented HTML-for-a-wasm-rendering-engine-defacto-standard is invented?
(This is more a rant against "let's reinvent html/css in canvas" rather against a VM-based javascript replacement in general. Even though the latter sounds a bit terrible as well for the open web; imagine what the web would have looked like if .js never existed, and a flash/java .swf/.jar engine was the only way to do scripting in a webpage.)
So when you start talking about ignore-the-DOM stuff, my strong suspicion is that it would all be completely and totally inaccessible.
I’d argue we already lost.
The browser becomes a simple kernel which knows how to execute a bytecode (their so-called "Syphon Interpreter.") The browser itself provides much simpler, lower-level APIs for doing I/O.
To actually render a page you still need a layout engine, a renderer, and maybe a scripting runtime. The difference is these components are provided _as bytecode at runtime_, they're not shipped as part of the browser itself.
Your page then specifies the environment it needs by requesting the different components you need. Then you just let the environment go to work on whatever page you served.
---
[0]: http://research.microsoft.com/apps/pubs/default.aspx?id=1546... [1]: https://www.youtube.com/watch?v=4c0DdOvH6lg
There are at least two distinct types of content - structured/unstructured content that should be exposed and can be indexed via some known mechanism by external visitors, and application content that perhaps need not be indexed.
This might be a time to evolve/establish what those mechanisms are for the betterment of both application development and content development/sharing.