I personally would love a "document web" and an "application web." I've thought of this before independently and talked about it to some people, I think the author is right, the idea of one client application for everything internet related is a core source for the problems we face with the web. I like Gemini, a lot, and I think it could serve as a "document web" very well, except it's missing certain document featur…
Why does it have to be so siloed? What if I want documents with a slight bit of inactivity? Why must I go through two different protocols? What if I want to read a paper next to the Juyter notebook that made it? I think it should be the clients job to take whatever slice of a richer universe it wants. This also stops duplication of effort, why maintain separate protocols and clients etc. It’s just a search issue, the…
I don't see why a document couldn't have a link to an application that opened next to it, so that you could view documentation and an application together. We should utilize the organizational ui paradigms built into our operating system, not use the system as a launcher for Chrome.
The effort is being done whether its all in one application or split into two.
It has to be siloed because if it isn't, you won't be able to find the document you want to read without running application code, as we see with the modern web. It's not a search issue, I find the documents I want to read just fine, it's just that they come with megabytes of executable code I don't want to run.
It would be nice if a client could only implement the rich stuff that it wants to, unfortunately, when the rich stuff is all different everywhere, it means only clients that support all of it get used, hence the current state of web browser development.