It will be like a VM plus an OS API:
-DOM replace GUI frameworks (like Qt)
-Canvas replace framebuffer (or GDI)
-JS File API replace fopen() (or with emscripten virtual FS)
- ...
We can see JS as a higher level shell and the Web API as a cross-OS POSIX.
It's simply not a suitable performant model for a GUI event/render tree.
If some non-renderable DOM tree could be cloned and transferred across threads you could basically operate in a clone-modify-splice cycle across threads.
I think it's salvageable. But before you can even think about concurrent APIs you first need threads/parallel task executors. And Web Workers aren't going to cut it because they dictate what you're allowed to send (structured clone) instead of being extensible.
Does anybody seriously think that the people that try to disable the right-click context menu in a futile attempt to prevent people from using "save as" will bother to re-create copy-paste support? Is anybody delusional enough to believe that businesses will pay developers to add back in proper URL deep-linking support into their "app" with custom rendering that loads page content AngularJS-style?
Sure, those of us that know what we are doing can [decompile and] read the source and bypass the whole mess. That doesn't help normal people, and worse it's a workaround; links will still be broken. Additionally, who knows how courts will interpret "decompiling" WebAssembly. Does that count as a "technological measure that effectively controls access" under the DMCA?
The requirement of rendering to the DOM puts de facto limits on what can be done on the client, which is part of what has made the internet and the web so successful. Giving those that wish to lock up the commons the tools they need to build their own locks will be one of the worst things to happen to the internet. Unfortunately, I suspect that a lot of the people that should understand these issues will be distracted by shiny toys and promises about better tools and faster apps when they should be thinking about how the technologies they support will affect their future.
edit: fixed spelling typo
A horribly crippled version of that. Where's my inotify? where are my UDP sockets and epoll?
Security is the common objection to providing real APIs. But instead why not just sandbox them into containers which otherwise provide the full experience of what we already have instead of creating a dumbed-down wrapper?
In other words: Creating a restricted subset of POSIX apis certainly is a sufficient approach for security, but it is not necessary.
Or maybe this is a non problem, because everything will become native again on the mobile devices. No more html, no more Dom.
Pnacl already did this anyway without reinventing compiler ir in a goofy way.