It's actually because we programmers like to recreate things, because there's this itch and wonder about how stuff works.
Http hasn't changed that much.
Html did. It was hyper text, and rendering was done for document flow.
Then we could script a bit, and soon after we wanted "webapplications". Now, we lost probably 15 years trying to fit in an application-ui and lifecycle model in a document-flow model.
Html, or rather xml, or rather trees, are a good way to represent a user interface. Unfortunately back then, the only languages available were C++ and Java for any proper work oh yeah, and visual basic!).
Javascript, php, and perl were a godsend in terms of productivity. Just like the 80s home computers and basic. It just worked. Type and run. This is also why bad badsoftware gets popular btw..
Coming back to the post.. Lynx renders HTML how it was intended: as a document.
There's little value in me doing this, but I always have to push back against this idea. This is the hill I'll die on.
Most application UIs are not complicated. Most applications are just interactive documents. There is nothing special about 90% of the apps I use on my native computer that means they couldn't be rendered as HTML. The document model is fine for applications. Preferable, even.
Heck, a reasonable portion of the native applications on my computer have optional pure-terminal interfaces. If your application can work in a terminal, it can work with HTML -- and embracing a document model for your application UI would be a better user experience than whatever the heck pixel-perfect framework that everyone is chasing nowadays. That's true on the web, and it's true on native.
The problem with the web is not that HTML is incapable of being used as an application platform; it's not that we're trying to fit a square peg into a round hole. It's that both web and native developers overestimate the interface requirements of their applications, and bring in unnecessary cruft to achieve pixel-perfect layouts that are worse for end-users.
We have a square peg, and a square hole, but we like to go to conferences and pretend that our peg is actually some convoluted, recursive star shape.
Thank you for writing this. I had this feeling that the document model isn't that bad for software in the first place (a feeling that I noticed when I prototyped some of the stuff I was working on in Observable, and realized the prototype in an interactive notebook format fits the problem more than the SPA we were building). But I haven't considered the implications. You might be very right that the document model could support a lot more than we give it credit for, if we just stopped pushing the established "appliance" UI paradigm.
If you're talking about "forms" as the interface, then sure. I 100% agree. But the moment things get more interesting, you'll fail. Video editing for example.
Lastly, I believe that if forms suffice, you don't need any of the recent CSS features. Simple forms without css should be fine. So no panels, modals, popups, nested navigation or single page apps.
Html did. It was hyper text, and rendering was done for document flow.
Then we could script a bit, and soon after we wanted "webapplications". Now, we lost probably 15 years trying to fit in an application-ui and lifecycle model in a document-flow model.
Html, or rather xml, or rather trees, are a good way to represent a user interface. Unfortunately back then, the only languages available were C++ and Java for any proper work oh yeah, and visual basic!).
Javascript, php, and perl were a godsend in terms of productivity. Just like the 80s home computers and basic. It just worked. Type and run. This is also why bad badsoftware gets popular btw..
Coming back to the post.. Lynx renders HTML how it was intended: as a document.