The separation between documents and programs assumes we know ahead of time all the things people might want to put inside a document. The evolution of the web shows this not to be true.<p>Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.<p>For comparison, consider that apple just proposed adding a html tag to display 3D models, just like an image.<p>The problem is that even basic interaction with a 3d model requires complex controls. There is no single standard for materials and lighting. The going methods are optimized for photorealism.<p>So adding a model tag just means baking in a set of assumptions, and doing so before you have a good idea of the kinds of things people will want to do with it and can't.<p>This is the real story of the web: poorly conceived standards and APIs, frozen before the medium had time to find its feet. It's a horse designed by committee in a world of cars.<p>You could turn the question around: why should webpages be dynamic at all? Just make a dumb client that requests rendered SVGs from a server after a client tells you its screen size.<p>Oh but that can't work because it's not really a document, but a dynamically laid out program after all.<p>If you want to displace the single page apps of the world, design a "document" format actually capturing all the nuances people want from them... Or get off the pot.
I don't think the comparison between documents and applications is anywhere near as interesting as _why_ we've collectively decided to tie ourselves into knots to create applications out of documents over the past few decades.<p>It seems to me that the internet application model is far more attractive than the locally installed application model on any OS. As proven by, well, the past few decades.<p>I started out with BBS and when I started to play with the web, I thought mosaic and webcrawler were mind-blowing. I remember faxing in my info to buy domains and I know I had a geocities site, though ill never remember the name I used.<p>I'd done over a decade of server side rendering and knew, just absolutely knew, that client-sode rendering would be a massive improvement for all parties. And it can be when done well (I admit it isn't always). We're still many years behind where we should be in what our browsers should allow for client development.<p>What we're capable of now with what can still be considered an enormous collection of "documents" is just incredible. I'll take this over those days. What I personally miss most is the ability to read the uncompiled code. That's where we lost the most, as that's where I learned almost everything.<p>And after 20 years of professional development on multiple platforms and languages, I still largely prefer web development. I'm far from alone. I think that says a lot more about classical "application" development than it does about the web.
I thought this was gonna be about how we've been tying data or documents in native mobile apps to their program of origin, making the use of several apps on a same document very complicated (or importing data from other apps). iOS went all hog on this and it's been a pain for "pro" workflows.<p>Instead it's complaining about bad JavaScript usage and needless "apps" for "personal websites", which by the definition of the author are just documents to be shared. I love badmouthing SPAs and needless JS like anyone else, but what if I want a bit of interactivity such as comments? Am I not allowed to do that on my personal website by the author's definition?<p>I think most importantly it misses the point that the web never was about defining documents. HTML was about linking pages and resources together. And even early on, CGI was a thing, and interactivity quickly became the "killer app", starting with search.<p>I mean, Mosaic added forms in <i>1993</i>. [1]<p>[1] : <a href="https://www.w3.org/People/Raggett/book4/ch02.html" rel="nofollow">https://www.w3.org/People/Raggett/book4/ch02.html</a>
<i>"An idiot admires complexity, a genius admires simplicity."</i><p>Yes, and most of the idiotic complexity on the web today is the result of people insisting that instead of clearly defined execution and communication models all we needed was a document with some "extra features". Admit it. Alan Kay was right. All the web developers were wrong.<p>I like simple HTML. I even design most of my web stuff so that it works without scripts. However, the idea that documents are always simple and programs are always complex is wrong on the most fundamental level.
Personally, i agree with many of the claimed benefits of server side rendering or focusing on static content. In my opinion, a web that would be closer to linked documents of the old days and would also use regular forms more liberally would probably be far more simpler and user friendly, than the bloated and highly interactive sites that we see nowadays.<p>A lot of what we see today is simply chasing towards new trends that have been set by few of the giants of industry, dragging the rest of the market behind them and affecting hireability of those who know or don't know how to utilize these technologies. Not every site needs React, Angular, Vue, however at the same time there's also something to be said about how those don't make you run into some of the problems with stale state or every integration having its own mechanisms to tackle those problems, that jQuery had in the instances where you actually wanted dynamic sites.<p>Regardless, i still think that far too many websites are dragged along and coaxed into using those technologies, which, when combined with ads, analytics and numerous other scripts as well as various design elements can lead to those sites being far too heavy for my liking. For some examples, look at the "Website Obesity Crisis" talk: <a href="https://idlewords.com/talks/website_obesity.htm" rel="nofollow">https://idlewords.com/talks/website_obesity.htm</a>
> Furthermore, you're recreating functions of the browser almost immediately. There is no need to do that. The user is already running a program that can do everything your code does faster. All you have to do is put the content in the right format and it's all handled for you.<p>There is a good reason to do that. HTML has no templating abilities built-in, which has a lot of downstream effects. Most sites benefit from a templating system, because most of their pages are very similar. I.e. each blog post has the same nav bar, each item in an ecommerce store has the same format.<p>You can pre-render those pages, but that becomes more and more difficult the more pages you have. Incremental builds exist, but tend to get buggy. As soon as you have a site that becomes too large to rebuild for each change you get, things become problematic.<p>Javascript fixes this because it allows you to treat your content like a template that accepts data. Updates are near-instant because it's often just modifying a database row.<p>I'm certainly not saying the current environment is perfect, but HTML-as-documents is fading because it's a restricted subset of the things you can do with HTML + Javascript. It's the same reason I don't see a lot of people logging directly into the terminal in Linux. Sure, it can do a lot of what I want it to do, but I can get a terminal in the GUI even if it's slow. The GUI can also do a lot of things the terminal can't, so I log into the GUI by default.
JavaScript has it benefits, live updates and interaction! I'm programming myself with it because I have to do so. But the current usage of JavaScript is driven by cost savings and manipulating users and not actual technical needs. I blame especially Mozilla, that they didn't stop that early. The removal of the option to turn off JavaScript from the GUI was wrong.<p>I can recommend as test for you, to turn off JavaScript (about:config -> javascript) and check out how web works for you. You will notice that Amazon works well and quick, it is a website. You will lose some comfort features on Stackoverflow, but still a website. Single-Page-Applications will not work - but at least you won't download unknown JavaScript from CDNs and your webbrowser will not execute it and spin up your fan. Interesting enough it are news website which tend to break, their advertisment-networks and paywalls need JavaScript.<p>Of course there are good single-page-applications and there is stuff, which is better handled solely online. The old 3270-Emulations are an example for this.
In most cases your professional users will appreciate desktop-applications, which store data locally, work fast and reliable stand-alone and uses server for syncing but not for execution. Updates could be part of the synchronization or you use modern stuff like FlatPak. Yep - you will have to pay application developers for this which will cost you money. But money? If done right you won't need to close your supermarkets next time you have an server outage, your clients switch to standalone mode and sync later the bills to the servers. That can safe a lot of money. And your admins can fix the server in meanwhile.<p>As a consequence the web will be maybe a lot of faster and safer, too.
The author cites two examples of "unnecessary complexity on websites."<p>The first, <i>in the linked post</i>, states<p>> It’s massively over-engineered! But that’s the point: learn, have fun and enjoy slowly hacking away after the kids go to bed.<p>So even if we conclude that the cost-benefit of the application-like functionality of this person's site slants toward cost (this isn't actually argued, of course), the creator of this site <i>agrees</i> -- it's just that the fun and learning make it worth it.<p>About the second example, the author states "Why was it designed this way? I couldn't tell you. It reminds me of a quote: 'An idiot admires complexity, a genius admires simplicity.'"<p>Well, one reason why it might have been done suboptimally is that the creator is a college student (<a href="https://slc.is/#About" rel="nofollow">https://slc.is/#About</a>). Nobody learn in public where this guy might find it, I guess, or you're an 'idiot'.<p>If you're making this argument without reckoning with the pros and cons of the application paradigm in professionally engineered websites, you're not serious about the argument and you're just being a jerk.
I agree with the author in general. I think the web would benefit from a better distinction of documents and the web. However it is not that easy, because there are valid in-betweens, like Jupyter notebooks. Therefore I'd prefer a real <i>progressive</i> web over a document web and a app web. <i>Do</i> the fancy features, but also make sure your site works in a very simple environment.<p>A blog should be readable everywhere, even in lynx. Interactive, discoverable documents and multimedia content should include a text fallback if possible. And <i>real</i> apps like a photo editor -- well they need to be executed.
I see quite a few blogs and informational sites with this described setup where the base html has none of the content and everything is client-side rendered.<p>I'm curious what the counter argument is...why do people want to do this? (edit: specifically why for blog posts and informational pages.)
JavaScript free Static sites are great for many reasons:<p>* Nothing to hack except the webserver<p>* Fewer moving parts to break<p>* Fast loading<p>* Cachable<p>* No Flash of unstyled content or other client rendering anomalies which people code around<p>* SEO crawling without JavaScript<p>Edit:<p>Javascript free static sites.
Broadly speaking, there are 3 types of media web: documents, interactive documents, applications. The Web is great for the first two and not so great for the last one.<p>The difference between interactive documents and applications is that users will reuse applications so they need to be snappy to leverage muscle memory. There should be no delay going to another screen, even if there's a delay in updating the data in it (due to latency) and that's where, IMO, there's a huge opportunity for improvement.
100% agree, and a LOT of websites out there are glorified documents.<p>I'm ok if you want to add a bit of interactivity, but you don't need to go full SPA for that and break caching, navigation or scrolling in the process. Vanilla JS is enough, or petite-vue if you wanna get fancy.<p>Honestly for most sites, I just hit reader mode preemptively, especially on mobile.
This is vastly oversimplifying the concept of a “document”. Many times, documents have dynamic content, and therefore must be processed through some kind of controller back-end.<p>Another thing I disagree with:<p>> On-the-fly "building" of documents is, quite literally, fixing something that is not broken.<p>With modern tools like Markdown converters, we can make authoring of documents far easier than hand-coding HTML, so while building documents on-the-fly is less efficient, the efficiency actually shifts to the authoring side of things, and the cost to do conversion is trivial (in fact you could do JIT conversion and cache the result on the server so that subsequent request only delivered the cached cached version).
Interface-wise, a document is a static application and an application is just a dynamic document. In the flat 2d-world of computers they both are opposite ends of a spectrum and it's somewhat natural to move on this spectrum from one side to the other depending on your requirements and circumstances.<p>From pov of the user on the other side the document is the result of a program, but you still open and interact with it from an application, thus we are back to the spectrum. Except with webstack we have better options to deliver a more content-optimized interface, leaving out some hoops, allowing to enhance the experience faster.
One well written document can spin out many programs. One well written program cannot spin out a well written document. Is up to savvy developers and ultimately a computer to give thumbs up to a program. A document on the other hand has a subjective bar for approval. When documents and programs clash (the program not doing exactly what the document asks), to people's chagrin, the program wins.
Hey, I wrote this! I guess now's as good a time as any to make an account. I wasn't very happy with this one when I uploaded it, but I didn't want another file in the blog graveyard.
Obligatory link to Gemini which needs to be posted in every HN thread where people complain about the complexity of the web:<p><a href="https://gemini.circumlunar.space/" rel="nofollow">https://gemini.circumlunar.space/</a>
I am getting so burnt out on the condescending 'old guard'. I have no time for graybeard curmudgeons.<p>OP linked two websites as bad examples... and they both totally work, so what?<p>"You can even run into serious security flaws" prove it, hack it.<p>"you get compatibility issues" worked for me<p>"Web was to be a set of protocols and formats used for the purpose of publishing documents" i only use my computer to crack nazi codes.