6 ms·

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 aut

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 features like italics, bold and superscript. If you want a document format that serves the average user's needs, you need those features, period. With superscript you don't need inline links for citations. An "application web" could just be a UI framework that renders an easy to write and read markup of some kind and fetches it over an internet protocol. The problem with the distinction is it doesn't solve another core source of the problem, specifically, the reason document delivering websites send applications instead is that they want to track users and serve targeted ads. What's to stop CNN from just sending a message in your document web browser saying "please use your application web browser to view this page"? And that's precisely what they'll do, and then you're in the same boat we are in right now, minus the complexity possibly, and nobody will use the document web at all. How is this problem solved?

enobrev 4y ago
Sounds like more of an indexing problem than anything else. Add a no-js switch to our search engines and you can read all the plain text your internal organs can handle. I tend to like today's web (a bit too corporate for my taste, but I like the potential for variety). But there's no reason the modern web can't look like the old web with the right filters.
- betwixthewires 4y ago
  It's not just about finding just text to read, it's about finding the documents you want to read and not having to run arbitrary application code to read it.
fennecs 4y ago
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, there are plenty of text websites out there. Protocols like Gemini I think are a waste of time.
- kitsunesoba 4y ago
  The problem with "one client to rule them all" is a massive lost of consistency, speed/responsiveness, and usability when it comes to documents. On the web, documents can come in anything ranging from the form of a tiny text file to a gargantuan "app" that weighs tens of megabytes and spins up your laptop's fans to render. It also means that the browser isn't nearly as smart as it could be because it has to be a general purpose jack of all trades. A dedicated document browser would likely almost always blazing fast, regardless of the machine it was run on and the network over which the documents were transferred over. It could have features that would make no sense in a web browser but greatly enhance the experience of reading and navigation. It could reasonably cache nearly everything the user visits (since it's practically all read-only and small) to reduce server load and increase speed. In a nutshell, it could be far better at specifically working with documents than a web browser ever could, even with a laundry list of extensions installed. Additionally, it would actually be possible to write brand new competing document browsers due to the vastly more simple specification, which is something the web will probably never have again.
  - 6keZbCECT2uB 4y ago
    I find this compelling, but the lines feel blurry to me. For example, take Hacker News. When I read hacker news, it's both static and simple. But, if I want to make a comment, suddenly I need authentication and a text box. So, does all of Hacker News have to be in an application web to support comments? Do I have to use two different applications to read or submit comments? Next level of complexity might be form entry. Say I want to buy tickets for a conference, and need to submit my credit card information, phone number, address, etc. We already have authorization from HN, but are the credit card and phone number boxes just plain text boxes? No validation or interactive feedback until I POST? When I enter my address, do I get a map of where that is so that I don't confuse N xx-th St NYC with xx-th St NYC, one of which is in Brooklyn and one of which is in Manhattan? On the flip side in the application web, when I'm doing my banking. If you go all the way to pixels, how does my accessibility reader handle it?
  - DeathArrow 4y ago
    The problem with one client is that the client is made by a corporation whose interests are not aligned well with the interests of the users and of other companies. One company owning the Web and practically dictating standards, what users can do or not do on web, it's pretty damn bad.
virchau13 4y ago
Where would https://ciechanow.ski/mechanical-watch/ https://ciechanow.ski/mechanical-watch/ fall? In the document web or the application web?
- lifthrasiir 4y ago
  It can fall under any of these with minimal changes, so your question is not very meaningful. I'd say it is better suited for the application web though, because you expect interactivity. The point here is that there are not many documents that do necessarily need interactivity.
  - virchau13 4y ago
    But that article is exactly what we want on the internet. It's the kind of interactive teaching demonstrations that forward looking educators have been thinking about for decades. It's not bloated or overdone; it doesn't take up significantly more processing power; it works far better than a traditional article ever could. This is what we desire the internet to be like. It's because of articles like this one, or 3Blue1Brown videos, that I feel like the idea of "the document web" is really a step backwards: the internet is not just a glorified transmission method for paper anymore. We have computers, which are able to do so much more than paper ever could. To not exploit them for their capabilities, simply due to fear of exploitation, is far worse. How much worse do you think https://thebookofshaders.com/ https://thebookofshaders.com/ would be to learn from if it couldn't include live editable demnostrations? To divide up the web into "interactive" and "non-interactive" content is to remove the ability for creators such as the author of the Mechanical Watch article to add progressive interactivity to their documents, remove the ability for learning resources to fully utilize the power of computers, to remove the ability for small fun things to be added to sites such as a Konami Code easter egg or https://bruno-simon.com/'s https://bruno-simon.com/'s interactive website. And before you reply with something like "these would all go on the interactive web", my point is that dividing the web like this would not only be pointless but would also be ultimately harmful to the creation of things such as these.
    - 4y ago
danielvaughn 4y ago
I’ve been thinking about this as well. Something like an application markup language. index.aml with an application object model. No idea what it would look like, but I’d love for html to just be allowed to be html.
gmueckl 4y ago
The distinction can be maintained easily by limiting the application client in its ability to display fancy text. In fact, it should have very little support for styling and layouting should be restricted to some nested grid like dynamic system without pixel perfect control. Part of the predicament of the current web is the expectation that you get fancy corporate designs reproduced pixel perfect everywhere. Break that for applications and you will limit the viability of reader applications for content that should be served as documents. Imagine a browser that throws out almost all CSS the moment it sees a form tag or a line of javascript.
zozbot234 4y ago
> except it's missing certain document features like italics, bold and superscript There are ANSI escape codes for these features. It's not missing.
- xigoi 4y ago
  Those don't work on every client.
achenet 4y ago
you solve this by leaving an ad supported business model in favor of asking for donations. Write a document website with a Patreon like gwern.net instead of some bloated ad-sponsored clickbait like BuzzFeed.
account42 4y ago
> I like Gemini, a lot, and I think it could serve as a "document web" A document web is dead in the water if it does not at least support the things that are common with physical documents. That means inline images and at least some control over layout. Gemini throws out way more than what would be justified with the document/application distinction and as a result doesn't have a chance of meaningful adoption. Maybe that's OK for the people behind Gemini, but that still leaves the role of the "document web" for the rest of us.

enobrev 4y ago

Sounds like more of an indexing problem than anything else. Add a no-js switch to our search engines and you can read all the plain text your internal organs can handle. I tend to like today's web (a bit too corporate for my taste, but I like the potential for variety). But there's no reason the modern web can't look like the old web with the right filters.

betwixthewires 4y ago
It's not just about finding just text to read, it's about finding the documents you want to read and not having to run arbitrary application code to read it.

fennecs 4y ago

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, there are plenty of text websites out there. Protocols like Gemini I think are a waste of time.

kitsunesoba 4y ago
The problem with "one client to rule them all" is a massive lost of consistency, speed/responsiveness, and usability when it comes to documents. On the web, documents can come in anything ranging from the form of a tiny text file to a gargantuan "app" that weighs tens of megabytes and spins up your laptop's fans to render. It also means that the browser isn't nearly as smart as it could be because it has to be a general purpose jack of all trades. A dedicated document browser would likely almost always blazing fast, regardless of the machine it was run on and the network over which the documents were transferred over. It could have features that would make no sense in a web browser but greatly enhance the experience of reading and navigation. It could reasonably cache nearly everything the user visits (since it's practically all read-only and small) to reduce server load and increase speed. In a nutshell, it could be far better at specifically working with documents than a web browser ever could, even with a laundry list of extensions installed. Additionally, it would actually be possible to write brand new competing document browsers due to the vastly more simple specification, which is something the web will probably never have again.
- 6keZbCECT2uB 4y ago
  I find this compelling, but the lines feel blurry to me. For example, take Hacker News. When I read hacker news, it's both static and simple. But, if I want to make a comment, suddenly I need authentication and a text box. So, does all of Hacker News have to be in an application web to support comments? Do I have to use two different applications to read or submit comments? Next level of complexity might be form entry. Say I want to buy tickets for a conference, and need to submit my credit card information, phone number, address, etc. We already have authorization from HN, but are the credit card and phone number boxes just plain text boxes? No validation or interactive feedback until I POST? When I enter my address, do I get a map of where that is so that I don't confuse N xx-th St NYC with xx-th St NYC, one of which is in Brooklyn and one of which is in Manhattan? On the flip side in the application web, when I'm doing my banking. If you go all the way to pixels, how does my accessibility reader handle it?
- DeathArrow 4y ago
  The problem with one client is that the client is made by a corporation whose interests are not aligned well with the interests of the users and of other companies. One company owning the Web and practically dictating standards, what users can do or not do on web, it's pretty damn bad.

virchau13 4y ago

Where would https://ciechanow.ski/mechanical-watch/ https://ciechanow.ski/mechanical-watch/ fall? In the document web or the application web?

lifthrasiir 4y ago
It can fall under any of these with minimal changes, so your question is not very meaningful. I'd say it is better suited for the application web though, because you expect interactivity. The point here is that there are not many documents that do necessarily need interactivity.
- virchau13 4y ago
  But that article is exactly what we want on the internet. It's the kind of interactive teaching demonstrations that forward looking educators have been thinking about for decades. It's not bloated or overdone; it doesn't take up significantly more processing power; it works far better than a traditional article ever could. This is what we desire the internet to be like. It's because of articles like this one, or 3Blue1Brown videos, that I feel like the idea of "the document web" is really a step backwards: the internet is not just a glorified transmission method for paper anymore. We have computers, which are able to do so much more than paper ever could. To not exploit them for their capabilities, simply due to fear of exploitation, is far worse. How much worse do you think https://thebookofshaders.com/ https://thebookofshaders.com/ would be to learn from if it couldn't include live editable demnostrations? To divide up the web into "interactive" and "non-interactive" content is to remove the ability for creators such as the author of the Mechanical Watch article to add progressive interactivity to their documents, remove the ability for learning resources to fully utilize the power of computers, to remove the ability for small fun things to be added to sites such as a Konami Code easter egg or https://bruno-simon.com/'s https://bruno-simon.com/'s interactive website. And before you reply with something like "these would all go on the interactive web", my point is that dividing the web like this would not only be pointless but would also be ultimately harmful to the creation of things such as these.
  - 4y ago

danielvaughn 4y ago

I’ve been thinking about this as well. Something like an application markup language. index.aml with an application object model. No idea what it would look like, but I’d love for html to just be allowed to be html.

gmueckl 4y ago

The distinction can be maintained easily by limiting the application client in its ability to display fancy text. In fact, it should have very little support for styling and layouting should be restricted to some nested grid like dynamic system without pixel perfect control. Part of the predicament of the current web is the expectation that you get fancy corporate designs reproduced pixel perfect everywhere. Break that for applications and you will limit the viability of reader applications for content that should be served as documents. Imagine a browser that throws out almost all CSS the moment it sees a form tag or a line of javascript.

zozbot234 4y ago

> except it's missing certain document features like italics, bold and superscript There are ANSI escape codes for these features. It's not missing.

xigoi 4y ago
Those don't work on every client.

achenet 4y ago

you solve this by leaving an ad supported business model in favor of asking for donations. Write a document website with a Patreon like gwern.net instead of some bloated ad-sponsored clickbait like BuzzFeed.

account42 4y ago

> I like Gemini, a lot, and I think it could serve as a "document web" A document web is dead in the water if it does not at least support the things that are common with physical documents. That means inline images and at least some control over layout. Gemini throws out way more than what would be justified with the document/application distinction and as a result doesn't have a chance of meaningful adoption. Maybe that's OK for the people behind Gemini, but that still leaves the role of the "document web" for the rest of us.