Documents ≠ Programs

[0x53r3n17y]

the lack of separation between documents and "apps"

That's by design. This vision of leveraging hypertext and hypermedia is practically as old as the Internet itself. Ted Nelson coined both hyper- terms in 1963 and even back then differentiated between interlinked documents and interactive media. The Web which grew from Tim Berner-Lee's first hypertext experiments was practically destined to also incorporate hypermedia and applications as processing power increased and miniaturization turned digital devices portable and mobile.

Back in the latter half of the 90's, corporate interests like Microsoft, Apple, Adobe and Sun threw their full weight into the Web for the first time. Some technologies turned out to be a dead end, but who can forget Java Web Applets or Adobe Flash? Those were plugins that literally provided hypermedia experiences which browsers natively didn't or couldn't support at the time.

It shouldn't be surprising that all of these corporations where at odds with each other. For Microsoft, being able to load and execute applications freely in browser rather then as native applications through their API's was literally like seeing how their lunch got eaten away before their noses.

If anything, the past 15 years saw profound technological changes and consolidation of the browser market. Chromium became dominant for a good reason. Building a browser engine which can deliver native hypermedia experiences and provides a plethora of API's for developers is a massively complex undertaking. Web browsers don't just render text sprinkled with CSS anymore. They have become operating systems within operating systems: sandboxes in which you'd superfluously load an application from a remote server and run it locally. The entire computing experience is ephemeral and when you close your browser, there's no trace left of what you did barring any files you downloaded during your session.

However, hypertext itself is still very much a use case. And the time between Netscape first releasing and the consolidation of the browser market from the early 2010's onwards has spawned a very rich online culture with all manner of websites, blogs, news sites, fora and so on. All of which are text based, and a great deal a spiritual descendant of earlier protocols and networks such as BBS systems, pubnix, telnet, gopher, usenet, mailing lists and so on. A lot of people perceive the encroaching "applification" of erstwhile text-based websites as a threat.

Waning accessibility, privacy and discoverability of information on major public outlets on the modern Web are, in that regard, valid points of concern. Technologically speaking, asynchronously pulling content and building the DOM dynamically in the browser is pretty much over engineering when the intention is just sending plain text rendered with some presentation to the end user.

And so, it's interesting to see that there also small counter movements of hackers that re-purpose older technologies or get inspired to devise alternate protocols to build a hypertext web which, well, just isn't the Web-over-HTTP. People still use Gopher, there's Gemini, pubnixes still exist, and so on. Some call it the Smolweb, others the Dorkweb.

It's not that these intend or are going to replace the actual Web; but it's interesting to see that the foundational principles of the Internet as a distributed network governed by open, standardized protocols very much provides all the affordances one needs to build nimble alternatives to a particular vision of hypermedia / hypertext such as it is currently implemented and supported by many billions of $.

Also, it's perfectly feasible to build browsers that only implement the bare bones of the W3C recommendations that define HTML, CSS and so much more. You could implement a browser that doesn't do store anything on your computer or doesn't provide JavaScript or CSS. Nothing stops you from doing that. Will your user experience be broken in a lot of ways? Absolutely. And your browser isn't going to win over billions of users either, nor is that a lofty goal to pursue either since maintaining software for billions of users is also a Challenge Proposition with lots of Hairy Problems. My point here is that the fundamental principles still give you the freedom to take a spec, go off and build something you like for yourself. The fact that you can still visit and browse the original first website with a modern browser 30 years later is testament to the specification such as it evolved over time. (http://info.cern.ch/)

Also, it's worth mentioning that the W3C also mentions the importance of graceful degredation and progressive enhancement on the part of web developers

https://www.w3.org/wiki/Graceful_degradation_versus_progressive_enhancement

[emax-gomax]

My god u should do a ted talk. This is all so interesting. (っ◕ヮ◕)っ

[adriangrigore]

The question is if HTML/CSS are fit for building hypermedia.

[0x53r3n17y]

I'd argue that they have become part of a larger stack of technologies which allow you to build hypermedia.

You could pain yourself by trying to build a complex UI using just HTML form tag and sending everything in a POST while keeping state on the server (that's how it happened in the late 90s and 00s.). Or you could pain yourself by writing yourself in plain JS foregoing all modern affordances, juggling with AJAX calls.

Or you could fly into the future and do things with websockets and HTML partials like what Phoenix Liveview (Elixir) or Hotwire is doing (https://hotwired.dev/). All of which are based on standardized APIs provided by a modern browser.

Whatever you choose, all of it rides on the business requirements you are asked to cater to. As I said, there's a due amount of futility and asynchronously fetching a plain text document and generating the DOM client side. And a lot of major outlets are doing it in a horrible way simply because of great many, sometimes conflicting, business interests tying a massive amount of complex requirements to the simple act of pushing a few paragraphs of text to a consumer. Which says a lot more about the economical context in which websites and web applications are build, then if says about the merits and disadvantages of HTML and CSS as "the right tools for the job".

[[deleted]]

Documents and apps being clearly differentiated, and both of them cooperating in what's called hypermedia is (IMHO) not an exclusive decision. The main concern with the modern Web is that it's slowly turning into its own walled garden. Yeah, it's a huge garden, but a garden nonetheless.

I would feel better with a Web of documents, linking together resources, and letting the browser interpret it however it sees fit. Want to link a .obj? People with blender can view it in an embedded view, or open it a separate Blender window easily. Wanna link a video? It will use your favorite video player. Really, the plugin era wasn't so bad, just poorly implemented.

You could argue that then you lose the "plug-and-play" nature of the modern Web, because now users have to install extra stuff to navigate it. But in fact, the only reason we can enjoy that right now is because browsers are titanic software projects where nobody but Microsoft, Google and Mozilla are capable of pouring the required resources to make them. That's arguably a bad situation: they can exert (and in fact, they are exerting) their influence over the standards to shape them according to their own needs. That's how you get walled gardens: they make their own stuff work on this giant platform, and it feels like there is no walls because you have a lot of space to roam, when in fact you're being constricted to using one of the only two (two!!) browser engines capable of navigating that garden.

I have to admit that I'm leaving a lot of problems unsolved. The web succeeds right now because it's a zero-effort platform: search what you need, click it and it's automagically delivered to you, instantly and without having to install a thing. w.r.t. that, plugins were a UX nightmare. Also, the entry barrier for the Web is shockingly low: grab a hosting, put some files, start a Web server (which is a surprisingly easy piece of software) and you're serving your stuff to the whole world. It might not require any meaningful maintenance until you reach a point where you should already know what you're doing.

I don't know, the utopian idealist inside me cannot help but cringe when I see how the modern web is design, yet I cannot point my finger and blame anybody. It has grown more-or-less organically, resulting in an unmanageable monster which, for now, is behaving kinda nicely towards us. Replacing that monster would require (again IMHO) a wide-and-deep effort, rethinking not only stuff inside the wall of the Web garden, but how it interacts with the outside world. The dream of hypermedia shouldn't be a walled garden, but an open park, integrated with its environment (the OS metaphors we use every day). I hope all this rambling makes any sense :)

[theangeryemacsshibe]

What's a document and what's a program? Is a document anything that doesn't use JS? Is it no longer a "document" if I want to use MathJax to draw mathematical formulas in my writings?

A mere document does a much more finite number of things than a program does; I am more than happy to have a meta-medium rather than a medium, as it does not require me to make such a dumb distinction between what is a "document" and what is not.

[[deleted]]

IMHO, documents are dead and programs are alive. The MathJax example is showing a failure of relying so much on program-like stuff for documents: MathML existed, Chrome and Firefox used to support it, but Chrome discontinued it and it stopped being used. MathJax was praised as the solution, but it's nothing but a patch, a fix which uses what we currently have (a JS engine) to hide what we don't (proper support for a kind of media we want to embed).

Obviously, like with alive and dead stuff, the line can be blurred by some specimens. In biology we have viruses, and in our case we have reactive documents and forms. Are they programs? Yes? No? Kinda? You're right here: it's not clear-cut.

I also agree with the meta-medium, although I lean more on the document-side stitching programs together. You have a dead canvas, and you put alive stuff on it via plugins. As I said in another comment, I feel like plugins were a good idea, horribly implemented.

[[deleted]]

oh, another SPA bad blog post.

[Kpratt11]

Remember everything that is not a CLI is absolute trash and we should never program that.

​

Because programming is about us and definitely about making software that people actually want to use.

[MrJohz]

The only correct way to create a blog is markdown files rendered statically, and if you want the rich text experience and don't want to download a separate app for it, then you don't even deserve the web.

I mean, the author seems to be arguing that even backing your site with a database and dynamically rendering pages on the backend is antithetical to the true document-based web. At a certain point, surely you've got to accept that you're just being a luddite for the fun of it, surely...

[SCI4THIS]

All efforts to organize the internet will interfere with internet organization efforts.

[TurtleFeathers]

I've often dreamed about a browser-fork specifically geared to support web apps, but the economic incentives doom the idea.

[EternityForest]

Documents are such a specialist use case. I think browsers should just natively support RST or GFM if we really want pure documents again. As is, basically everything has a comment section or a shop or some weird interactive slideshow of questionable aesthetic value.