I submit that Tannhaeuser's vision is what can replace the current web in its cross-platform-app-distribution role, leaving the document-browsing side to mine :-)

That addresses the core problem, as I see it, which is that when I want to browse some damn HTML I'm subjected to a ton of actual user-hostile behavior and lots more potential hostile behavior that I have to worry about, all while paying for it in disk space, memory, and processor cycles (so, paying in terms of battery and UX). Mixing the two is why the Web sucks so very much. Separating them into a document-browsing client and a sandboxed-app client is precisely what I wish would happen. I don't want a link in my document-browsing client to maybe open an application without telling me, nor for it to have access to all that capability when I just want to read Wikipedia or whatever, and trust that the links I follow won't lead to some "page" that spies on my every mouse movement, mines Bitcoin, auto-plays video ads, pops up "SUBSCRIBE TO MY NEWSLETTER" modals, or any crap like that.

I'm pessimistic about strict semantic markup/typing of data being viable as a web replacement, as in JohnStrange's suggestion.

So under that model, would Wikipedia, which uses javascript, be in the sandboxed-app client, and would you would be perfectly happy viewing it with javascript on, in that case?

I'm curious which sites you actually frequent which wouldn't count as "apps," but which still use javascript, and which would actually run in the static-only client you seem to prefer?

My own personal vainglorious idea about the opportunity missed with the web is much more radical yet.

Semantic markup (remember, TBL originally designed HTML this way) failed already once for a reason. Markup language was a bad choice to begin with.

Instead of an SGML-derived markup, we should have had a set of primitive s-expressions that were supported in a standard allowing people to extend the behavior of browsers by implementing renderers based on any kind of s-expression. Wanna extend your browser? Just implement a renderer. Wanna distribute a renderer? Fine; the interface of renderers are part of the standard. You can distribute the renderer along with your page.

There would never have been JS to begin with: that gets handled right out of the box with s-expressions.