[betwixthewires]

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?

[fennecs]

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]

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]

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]

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.

[grishka]

> What if I want documents with a slight bit of inactivity?

Then you use Adobe Flash. See, we used to have a decent technology for when you want "a document with a slight bit of interactivity". It worked very well for this exact purpose. More than 10 years later, browsers' native capabilities, that are supposed to be a replacement for what Flash offered, have still not quite caught up. Moreover, Flash defined a clear boundary between the document and the application parts.

Did the particular (Adobe's proprietary) implementation of Flash player suck? Yes, sure. Could this have been done better? Yes, sure. Is it possible to reimplement a Flash player from scratch within a reasonable timeframe with a small team of developers? Yes, sure, Ruffle[1] is a thing, and it's being actively developed.

I miss Flash. I hope it makes a comeback eventually.

[1] https://ruffle.rs

[rektide]

This sort of "wouldnt it be great to have some other thing, so we can murder the rest of the web platform" is so grotesque to me, just repugnant & vile & cruel.

Flash is a comedically shit technology. There's a couple animation capabilities it had that were nice & simple & people adore it endlessly for that. But Flash hated users, gave them nothing, no power (alike a native app) & was a big proprietary anti-hypermedia ball of jank, and it had the most trashfire craptastic lack of accessibility one could ever imagine.

This desire to keep hypermedia down, to create hard walls between different purposes of apps... it feels poisonous & misguided. There is too much of the web today thay does abuse client side code too much. But frankly it rarely affects most people, there's still viable techniques for manipulating it (except for Flutter's CanvasKit which is an abomination more cursed than Flash), and honestly, we're still getting better at webdev, still learning, still emerging better libraries & best practices, & generally the urge to do better is here & slowly happening.

There's some really dark takes that we have to save the web from apps. That we should bring back Flash is one of the most unforutnate least justified most tragic hot takes I've heard though.

[gmueckl]

Your rant is focused so much on the actual implementation details of Flash that it misses the point that the abstract concept of a VM based application container/sandbox could have been a great thing. In fact, it was such a great idea that browser developers were forced into a pretty tough struggle to actually kill it in order to stay relevant themselves. Adobe's poor stewardship sealed the deal, not conceptual shortcomings.

[MrJohz]

Isn't that what we have? JavaScript is a VM-based sandbox. The difference is that JavaScript has more ready access to the DOM, but Flash was also able to do that, it just used JavaScript as a bridge.

[grishka]

The point is that you didn't need DOM. You had a canvas to draw things on and to handle clicks in. Now you need the DOM either way and it's cumbersome. It feels like trying to build a UI in a word processor. Text nodes are such a terrible idea...

[DeathArrow]

>Isn't that what we have? JavaScript is a VM-based sandbox.

JS is unfit for the task. It is a dynamic scripting language introduced by Netscape for the only purpose of adding a bit of interactivity to web pages, not to create large apps.

.NET and Java are much better for the task. The VMs support better languages with better libraries and more sane ecosystems. And the performance would be much better than that of JS.

And is easier to write an application using Xamarin or MAUI then using React.

When you write Java or .NET apps you write to target a computer which is a much better model for the apps then Web.

With "app languages" you can write apps better, faster while having better performance and more capabilities than using dynamic scripting languages like Javascript, Lua or Python.

Operating systems and browsers are apps too. And we don't use Javascript to write them.

You can write anything in any Turing complete language. But you'll be a fool if you attempt it for anything but fun.

[grishka]

Yes. The standard itself (the swf file format, the AVM bytecode, etc) is actually open. To their credit, Adobe has all the relevant specs on their website.

[iamcurious]

Cool, since you are here , is there any flash editor clone?

That was the stuff, animations, games, apps, all so intuitive.

[grishka]

None that I know of. Of course it would be nice to have an open-source editor as well, but an open-source player is much more important. You can get by with abandonware for the creation side of things, but you can't ask your site visitors to install abandonware that is known for an astonishing amount of scary vulnerabilities (if they use an OS that was supported in the first place).

[kixiQu]

https://www.wickeditor.com/#/ <-- I give these folks some money on Patreon because I feel like they're trying for the right thing

[chrischen]

Try https://tumult.com/hype/

[iamcurious]

Looks cool! But I don't own nor plan to own a mac.

[gitgud]

> I miss Flash. I hope it makes a comeback eventually.

Flash was great for developers, but terrible for users. The only good user experience was "flash games/animations" and even then they weren't responsive and a little clunky.

The Flash I remember was bloated "Flash" websites that had No HTML, No url paths, No SEO metadata, Terrible for accessibility.... but it was easy to develop for I guess...

[DeathArrow]

Why not just use Java and .NET? They have pretty capable VMs which support lots of languages: Java, Python, Clojure, C#, F#, Visual Basic, Python, C++ and others.

[na85]

>Why does it have to be so siloed? What if I want documents with a slight bit of inactivity?

You aren't allowed to have that, because it's not profitable for the web developer crowd's bosses. So your "slight bit of interactivity" becomes "several megabytes of surveillance and advertising".

[DeathArrow]

What if we're rebelling and make a new Web? If it will be interested enough, useful enough, both developers and users will come.

[Tyr42]

I think it's point 2. In the article, that it shouldn't be compatible, as you'll end up having to implement all of chrome again.

And the anecdote about adding the tracking code for one thing, but all the other market segmentation information getting turned on afterwards because it can.

But yeah, I do want comments on my blog posts, and hn linking to docs.

[betwixthewires]

So are you saying you just want the web as it is? If not, what would you change? How would you prevent it from becoming what it is now?

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.

[8note]

The web is about fine as it is.

The changes we need are around people, improving liberal arts education; and ownership, having government run alternatives to most things like search, login, and payments

[virchau13]

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

[lifthrasiir]

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]

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/ 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 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.

[lifthrasiir]

Don't get me wrong, I like interactive documents a lot, but they also take a lot of time and effort to produce and thus will remain a minority. Texts greatly outweigh every other medium primarily because they are very easy to produce and distribute.

[virchau13]

> they also take a lot of time and effort to produce

This is a case of bad tooling, not an intrinsic fact.

https://www.joshwcomeau.com/css/understanding-layout-algorit... is an article that could have easily been written without any interactive components. All the author did was replace traditional code blocks with an embed to a web playground (e.g. by s/Code/Playground/g in a MDX file). Ta-da, the demonstrations are immediately interactive.

> and thus will remain a minority.

Not if we put in effort to encourage them. On the other hand, if we put in effort to _discourage_ them (say, by splitting the web into documents without interaction and apps with interaction), they will disappear completely. It is not worth sacrificing these creations simply so that we can remove a few bad actors. (Mind you, there are many ways to act badly in non-interactive ways too. Image watermarks, embedded advertisements in videos, embedded advertisements in ASCII text...)

[lifthrasiir]

> All the author did was replace traditional code blocks with an embed to a web playground (e.g. by s/Code/Playground/g in a MDX file).

Well, not surprising given that the article was about the web technology (which powers the application web, of course!). I might have been convinced otherwise.

There is indeed some negative feedback loop going here. But I think the cost to achieve interactivity has been decreasing over the time (compare with, say, 1990s' interactive CD) and the gap is still very significant, even with a very favorable condition (nowadays you can practically have interactivity anywhere anytime!). I'm happy to be proven wrong, but for now I'm not optimistic about that.

[enobrev]

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]

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.

[account42]

> 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.

[gmueckl]

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.

[danielvaughn]

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.

[zozbot234]

> 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]

Those don't work on every client.

[achenet]

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.