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.
I'm curious what the counter argument is...why do people want to do this? (edit: specifically why for blog posts and informational pages.)
It's called "single page application" and my guess is the most reason is "responsiveness" (which is however not true, you can lazy load anything with traditional HTML and a few lines of JS) and "smooth" transitions from one "virtual" page to the other.
Honestly I never understood this trend. From a developer side, the engineering easily costs two times compared to a traditional site.
It's also usually a lot less responsive for something as simple as a blog. It makes sense for complicated text/media hybrid pages with animations, embedded images and video, etc.
There are so many "plain text" websites that simply do not load without JavaScript. Is this a consequence of using a framework like React? I feel like the world needs a "component-based" framework, but one that can gracefully degrade if JS isn't available.
> It's also usually a lot less responsive for something as simple as a blog.
It depends on how much JS is used and what it actually does. Sending and receiving data in a JSON format as opposed to receiving HTML? Could be marginally faster and would also allow integrating the API for fetching data with other front ends or other consumers easily.
What causes the actual slowdown most of the time is framework code which cannot have the unused bits removed efficiently because of how dynamic most of the languages that we use are, even if there are tree shaking advancements that you hear about every now and then.
That said, it's not entirely hopeless - you certainly can use something like react-snap to pre-render your site and then hydrate it with dynamic content and JS if supported by the user: https://web.dev/prerender-with-react-snap/
Of course, degradation won't necessarily be graceful - everything that depends on JS simply won't work, as opposed to have some theorethical server-side fallback component, as nice as that would be. I've also heard of server side rendered React, however, even though i haven't personally used it: https://www.digitalocean.com/community/tutorials/react-serve...
To be honest, trying to achieve such wide support for technologies and graceful fallback logic is a can of worms in of itself, so many simply choose to require JS functionality for their app and don't attempt to support other configurations, which is a shame.
I've come to think that such performance increases, if they exist, are not worth the amount of effort compared to a much simpler sever-side render.
Also, if your website just happens to have that one bit of information I care about, and I don't view other pages, rendering with Javascript is a complete waste.
Svelte [1] is a framework that's all about trying to make interactivity viz. JS a lighter process. It pre-compiles all the code so there's no shadow DOM or similar stuff going on.
But if you setup a lot of cool plugins with the newest bundler, add modern libraries and make good use of web workers and graphql, in a few months you can get your costs up to 5 or 6 times!
> But if you setup a lot [of libraries] ... in a few months you can get your costs up to 5 or 6 times!
Ah, lol!
But in all, SPA for SPAs makes sense, but for documents it's counterintuitive. I mean I can see a case where it might be worth it, but looking at Wikipedia maybe it's not justifiable for the increased maintenance.
Of course while the usual cause of rendering slowness in applications is emphasised (which is what I hear as a reason in favour of SPAs), but it tells me that your CSS isn't really optimized for your case.
It has a certain appeal to developers because it makes separation of concerns easier.
If your backend only takes in requests and spits out data, you can build the backend without spending any thoughts on user experience, layout, templates etc. All you do is design a database structure and API endpoints.
Which is ironic, considering the best way to improve your product is to delay the backend implementation until you have a well tested and validated user experience designed.
Because you can then derived a good architecture from that, but never the other way around.
But UI means dealing with those messy humans, while the backend is this nice quiet place where you can whisper to orderly computers.
As a backend dev, my projects started to get way better once I learned to not start with the database model and start to test some mock up on users first. Yet it's so tempting...
If you were using Django and rendering server side, then I don't imagine you would bother with a REST api layer. But, assuming the the data was already in some REST/JSON api, you would have a Django template filter that used json.loads(), right?
Either way - how does the front end developer get into play?
In a setup where the frontend is doing the rendering, you can give the frontend developer access to a directory with static assets that get output to the browser verbatim.
How do you give them the ability to "have a Django template filter" without them having the ability to mess with the rest of the backend? Or do you set up a second server that talks to the APIs of the first server?
I'm not in a Django shop, but I assume these problems exist anyway. Front-end developers probably also want access to templates, images and css that sit on a server. A template filter would be fairly static though, just converting json into python objects. How to give them access to the Django template itself would be the thing you would want to solve. Node.js seems to have considered some of this, since it's more common to co-mingle front/back end.
But I don't think Django templates are safe in a way that they protect the backend from a clueless or malicious frontend developer. Even if they were, you would have to take great care that you do not expose dangerous functionality. So "give them access to the Django template itself" is not enough. You would have to have a whole security concept around it.
And that is not enough. How does the fronted dev create routes? How do they create views, which are the glue between the DB and the templates?
Node.js is a runtime, not a framework. It does not have routes, views or templates at all. So that comparison makes no sense.
No matter which backend framework you choose - you will have a lot more work to bring the frontend dev into the game if you do backend rendering.
Please be aware that I am not against backend rendering. I indeed think that backend rendering is the better approach! I just explain here why there is some appeal to developers to write the backend as an API and do the rendering on the frontend.
Django templates intentionally provide greatly limited functionality compared to full-python.
The idea is that you prepare the needed data in the "view," and then the template should be relatively dumb. If the template is causing any database/backend requests while rendering, that's generally a sign that you haven't put enough information into your view layer.
By making Django templates and rendering them with the view the backend dev created. Django's original architecture handles this exact separation of concerns. A view creates a context dictionary (which is equivalent to a JSON response) and then the template is rendered with the context before being returned with the response to the client.
Usually, I see it done when the blog owner doesn't have a robust server or the savvy to run some shell scripts.
Many small blogs are hosted in servers with pre-configured static document sharing that won't let any server-side dynamic code run beyond "Fetch the static document at path X and echo it." In that context, you either need to run a framework that will assemble your dynamic page client-side, or you need to run a script that will pre-chew your blog from some more convenient format into a rich static HTML document and post it to the server.
A remarkable number of bloggers would consider that second option a bridge too far.
"Static sites" usually refer to a websites where the server is not servicing application requests because all resources are flat files precomputed ahead of time, not websites with no JS. Basically what you can get by opening files directly from disk. A site consisting of index.html and the gnarliest 10+ MB app.js bundle would still be considered a static site. Similarly, flash of unstyled content is a completely orthogonal issue. (In fact, FOUC is arguably most likely to be encountered on static sites, because the hosts they're on are usually chosen because they offer cheap/simple setup. So neither server performance nor the speed of rendering on the client for the HTML+CSS combo that the author goes with are necessarily given much attention.)
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.
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.
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: https://idlewords.com/talks/website_obesity.htm
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.
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.
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.
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.
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.
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.
>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'm curious why. For me, I've always been interested in keeping intellectually stimulated when I'm at work. I don't want impossible challenges but I want something that, while I'm working, time disappears so it doesn't feel like work.
Now, I did my fair share of server side rendering applications in the 2000s and enjoyed it at first. It was quite enjoyable to be able to pass my ideas and application around to others without the barriers of cross platform compatibility or security models that make running unknown or less known native binaries a no-no. This melted away with web applications (mostly, bar some pretty notable browser vulnerabilities during that era).
What happened really was Chrome's sandboxing and security overall that comforted many that running arbitrary JS code from an external source was "OK" because your browser was mostly protecting you from doing nasty things to your local system and data. This exploded into expanding JS, ES, and the entire development ecosystem.
To me, this is really what made things intriguing and I suspect why many love web development, they can easily share their creations now to about anyone without many barriers, just type in this address on your phone or laptop and tada.
Unfortunately, the development ecosystem is a mess. I don't think this says anything negative about classic application development, I love classic application development because it's usually well structured and I don't have to waste cognitive load dealing with silly technical issues I don't care about--I can focus on the application and what I want to create more. I don't want to know why this silly UI element isn't behaving the way it should and deal with a workaround, I just want a UI element that does this so I can move along and do the interesting work. What traditional application development really lacked was ease of portability for others to use securely.
The OS has now become the browser to many and this is their playground. Unfortunately I don't enjoy it because I'm used to mature frameworks where I don't worry so much about the application development as much, I worry about the application and translation of ideas into something people can use. Web development is getting there but it's just not there yet and if you've been spoiled with stable development environments it's hard to go back to the wild west of dealing with what you considered to be mostly solved problems decades ago.
I am pretty sure that getting what is basically a reliable VM style environment on every computer you can think of has way more to do with this than any other point.
I prefer programming in many other environments. I also greatly prefer not having to distribute anything to other computers.
That's not quite what the article is talking about.
The article is complaining not about the use of the Web to write/host apps, but about the unnecessary use of app-writing functionality (aka JS) to "enhance" documents or to reimplement browser document-reading functionality.
If you're writing an app, write an app.
If you're writing a news article, write a news article.
That's clearly stated, but not well supported by our experience. I agree that many sites are poorly implemented because they're trying to replace browser functionality with poorer versions written in JavaScript. This can be the fault of the service, host, or developer behind the site.
But browsers have not been improving their ability to serve documents.
Besides maybe initial load times (and fewer ads, whizzes, and pops), I get no significant benefit to reading an article with no JavaScript.
I don't get a searchable cache of my document history.
I don't get to swipe it over to some other device to continue reading without relying upon some other service.
I don't get some guarantee that the document will render on any device and that I can send the document to someone else without a url.
I can't highlight or add notes to a document or make corrections and view my (or others') versions of it.
Sure, they're documents, and so I should be able to treat them as such. But I can't. They're not portable. Browsers aren't really great for document management or manipulation. Static sites are just as tied to the browser and host as any app.
I think you're making the case that the web is a program-first medium and not a document-first medium. Is that correct?
While I largely agree that dumb documents aren't that useful, I'd say a large part of our actual web interaction is still just dumb documents with some form of response (like what I'm doing here, or site comments, as others do). That's not to diminish actual applications which are made much easier by the web's distribution model, like Google Maps or Google Docs.
Not quite, but I appreciate you for asking for a clarification.
The web is absolutely document-first. Our applications are _still_ just documents, which is pretty incredible.
I just don't think it's very good at being document-first. A sufficiently advanced document-first platform would have a lot more functionality in regards to reading, modifying, maintaining, and sharing documents. As far as any consumer is concerned, a basic note-taking app provides more functional use than a web browser.
That may be the reason it's become better known as a kludged together application platform derived from layers upon layers of workarounds - around a substandard document viewer with amazing plugin support.
If I'm making any point at all, it's that I don't accept the premise of the original post. The web isn't as good at serving documents as we tend to say it is, but it's become quite the application platform, because everyone seems to want it to be one. So who cares if people make crappy pages using JS when it isn't ideal?
I think we're pretty much in agreement here. I'll add that I think the web could have been a _better_ document (and application!) platform had folks separated the usecases early on instead of the piecemeal development that we have going on now.
The problem is if you want to write a news article about some tax policy and want to include sliders to let readers explore the likely outcomes, or a COVID article where you can see the difference between an r of 1.1 and of 1.14 you are making a much better news article, but you still need to write code.
> If your page includes a few non-essential scripts to do different things on the page, that isn't a problem. The document itself is still readable in a wide variety of programs and formats, regardless of support for those scripts.
I think you over estimate how many people would use the sliders. Or how many news sites have anything more interactive than video ever. And text the length of a news article should have something worth reading without the sliders.
I mean, "attractive" is weird here. Follow the money. People like cool things, and companies are reticent to make cool things in a way they can't control.
I've always framed it in terms of "where are the files?" Maximum control for the cool-making companies means "hide them from the users."
I'm really really really happy to see projects like obsidian.md that see the value in not doing that.
More seriously, I think I'm coming around to -- I don't care where or how the applications are made per se. I used to hate the web-stuff->desktop applications idea (electron et al) because it seemed dumb and slow, but both Discord and Obsidian disprove that pretty well I think.
It really is about "where is your stuff." It's fine to optionally store whatever in whoever's cloud. But increasingly, I believe that anyone developing any sort of application in which the user's stuff and how it moves around is not 100% transparent is quite literally evil and I wish them utter failure.
100% agree, and a LOT of websites out there are glorified documents.
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.
Honestly for most sites, I just hit reader mode preemptively, especially on mobile.
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.
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.
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.
As a consequence the web will be maybe a lot of faster and safer, too.
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.
Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.
For comparison, consider that apple just proposed adding a html tag to display 3D models, just like an image.
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.
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.
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.
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.
Oh but that can't work because it's not really a document, but a dynamically laid out program after all.
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.
Although on closer reading the OP does make a distinction between documents embedding programs, and programs that build up documents (like medium.com), which I agree is an anti-pattern.
I agree. The reason it seems like web standards are always “behind where we should be by now” is mostly a coordination problem, with some prognostication error. To work seamlessly, we have to agree on what the standard should be and implement it well, broadly, and consistently. That’s always going to be slow and patchy.
I don’t think it’s possible to anticipate exactly how everyone will want to use everything, but maybe we could reach a world where it’s easier to iterate on this.
For example, what if there was a way for the community to implement new HTML tags for their preferred browser? This could be implemented as an extension, though perhaps not under the dominant WebExtension paradigm. This would allow much faster iteration on the semantics of HTML within the secure sandbox provided by the browser. The IPFS extensions are a nice example of doing this at the protocol level.
Similarly, what if you could version HTML tags? That would be a bit of a nightmare, but would also allow authors to communicate more information to the browser about what functionality is expected from the tag.
Of course, this would lead to a strange ecosystem with many dependency management headaches for users. You’d have to worry about what new features were needed by the page you’re trying to view, which extensions you have installed, do they implement the tags you need, and do they do it well?
This would lead to “super extensions” that address many tags and become de facto requirements for everyone. Then those become security targets. Of course, they would have their own coordination process, parallel to W3C. This would become a business target just like W3C is, with google trying to manipulate it to liquidate user freedom to support advertising.
It’s hard to get big groups of people to work together effectively.
Strangely “we” can do that for linux, but cannot for the web. “apt install myapp” pulls the required trusted binary dependencies, if they aren’t there, and that’s it. Qt, wx, gtk, ffmpeg, mesa, you name it. Potentially malicious code is reviewed by distros and is not included, so if you want to distribute libhacky with your myapp, the entire ecosystem has to accept it before a user could trust it. But browsers are somehow different. I think the main reason is that browser vendors want their control over the market, and the entire issue is not technical/community at all.
It’s hard to get big groups of people to work together effectively.
One of the valid ways to deal with it is to let them work separately.
It doesn't work nearly as well in Linux as we'd want to impose such a design on the web.
"apt install myapp" works 95-99% of the time. The remaining time, you drop yourself into DLL hell of some flavor or other (package was poorly maintained, or your clone of the package repo indices is out of date, or you installed a local copy built-from-scratch of one of the binaries and it's now fighting with the distro binary, &c &c). And then remote tech support is impossible because for someone to provide support, they either need intimate knowledge of your configuration or you need to be running a stock configuration (and with very few, usually vendor-controlled exceptions, "stock configuration of a Linux distro" is a non-concept).
There was, ages ago, a paper describing what the design of a componentized browser rendering engine would look like (where pages could basically declare "I require engine components X, Y, Z" and the browser would have a library of them that could be spun up on a page-by-page basis). I wish I could grab a link to it; I think it may have been a Mozilla experiment? If I recall correctly, the complexity meant it never gained traction.
There was an experiment at Apple ages ago with the idea of reframing user interaction from the app to the document. OpenDoc (https://en.wikipedia.org/wiki/OpenDoc), which is remembered nowadays as an answer to Microsoft's OLE, was built around the idea that the nexus of programming could be not "What program is being run?" but instead "What data is being manipulated?" Different pieces of data would automatically invoke different code to interpret and / or modify them on-the-fly.
It was novel at the time, and we have something like that today in the form of the web browser... Though most data one fetches isn't intended for in-place editing, the convenient thing about web pages is that their hierarchical, dynamic, and self-modifying nature allow for a lot of the concepts explored in OpenDoc and OLE to be implemented within them.
An embedded map is definitely a document. The problem being that this document is too large to fit on your computer, so it needs to be stored on someone else's computer and therefore can only be accessed piecemeal.
> 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.
> Oh but that can't work because it's not really a document, but a dynamically laid out program after all.
What prevents one from sending a screen size and getting a server-side rendered SVG back with that exact screen size? It was a thing in Telnet days, and it's what Stadia/Mighty browser are doing. Not that I'm saying it's a good idea, but it is feasible.
> Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.
But it would be better if the application functionality of Google Maps was part of the document viewer (or selectable from within the document viewer), not of the document, because that gives you the flexibility to use your map viewer of choice, instead of being bound to Google Maps. That’s the point of separating document from viewer (and/or editor). Turning everything into an app reduces choices and interoperability.
> 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.
> Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.
I would argue that websites would be better off embedding an image of the location that links to a dedicated map viewing service like OpenStreetMap.
I might be in the minority here, but I always hate trying to use interactive maps in tiny boxes on people's websites.
Well, https://slc.is/ for instance, doesn't actually work. If I go there, and then click the back button, I get Error Page Not Found. An Error Page Not Found which isn't even a 404, because that would obviously have been to conformant.
This took me around 20 seconds to find, but I think I'll stop there :)
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.
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?
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.
> 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?
OP addresses this point well in my opinion:
> If your page includes a few non-essential scripts to do different things on the page, that isn't a problem. The document itself is still readable in a wide variety of programs and formats, regardless of support for those scripts.
If your post is still readable without JS, no one complains if the comments don't work. And no one complains, if you implement comments using JS.
The problem is, if the core content is actually a document, but behaves like an app (and you cannot access simple text because you disabled JS).
That's a very fair point, I guess I skipped over that part, my bad.
My core issue was around this and I should have sticked to it :
> The original purpose of the Web was to be a set of protocols and formats used for the purpose of publishing documents.
I still think this is a bad argument, I disagree that HTML was conceived as a way to make "documents", but it shouldn't matter, things evolve on their own and people may use your creation in ways you disagree with.
> The problem is, if the core content is actually a document, but behaves like an app (and you cannot access simple text because you disabled JS).
I 100% agree with you, but the distinction is the "core content" part.
Part of the page is that core content, and what we actually want to see/read indeed (and why various web browser brought a "reader mode" that extracts that part). But the page itself is not a document that only contains this core content, and hasn't been for a couple of decades.
Most blogs/publication, even personal ones have been backed by a publishing system with the core content in a database. At this point these are applications, and many of these system can still output "pages" that 100% fit the description of being easily readable without JS, while still adding a lot of utility. Hence my disagreement around the "Documents ≠ Programs".
The author is also not against using HTML/JS for things they were not initially intended for:
> It can be very useful to run certain programs in the browser. In a lot of cases, however, the same technologies are used for documents.
And yes, often the HTML is generated from a database. That's fine. "Document" does not equal "file on disk". The HTTP/HTML model just talks about the entities that actually hit the wire. If what you're delivering to the browser isn't a document, but rather a program running in the browser to build a document, you should be taking a deep breath and checking whether you actually need to do that.
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 progressive web over a document web and a app web. Do the fancy features, but also make sure your site works in a very simple environment.
A blog should be readable everywhere, even in lynx. Interactive, discoverable documents and multimedia content should include a text fallback if possible. And real apps like a photo editor -- well they need to be executed.
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.
> 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.
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.
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.
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.
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.
I think you're dismissing static site generators too quickly. An efficient static site generator will work very well for a lot of websites, because most of them aren't made up of >1,000 pages.
Static sites are better for those who don't want to enable JavaScript or who would like to save a copy of the page to read later. I'm sure there are accessibility benefits with less complicated websites, too.
Maybe I'm just strange, though. I log in directly to a TTY.
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.
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.
"An idiot admires complexity, a genius admires simplicity."
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.
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.
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.
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.
The author cites two examples of "unnecessary complexity on websites."
The first, in the linked post, states
> It’s massively over-engineered! But that’s the point: learn, have fun and enjoy slowly hacking away after the kids go to bed.
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 agrees -- it's just that the fun and learning make it worth it.
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.'"
Well, one reason why it might have been done suboptimally is that the creator is a college student (https://slc.is/#About). Nobody learn in public where this guy might find it, I guess, or you're an 'idiot'.
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.
Thanks, kixiQu. I'm the author of the linked post and I enjoyed - and agreed! - with much of the thinking behind the original article. I'd use a static site generator in a normal use case, but I think it's fine to experiment on my own site.
I'll admit I was a bit too harsh about it. I saw an opportunity to use a Terry Davis quote and took it.
There's nothing wrong with learning, of course. My point was that if you choose to introduce this unnecessary complexity you will likely end up with an unreliable website that alienates some visitors.
Most personal websites are made for the creator themselves more than they are for others, mine included. With computers, you should do what makes you smile. On the other hand, publishing something on the internet opens yourself up to criticism by others. There's definitely a lot of problems with my website, I invite you to write about it.
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.
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.
Another thing I disagree with:
> On-the-fly "building" of documents is, quite literally, fixing something that is not broken.
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).
73 comments
[ 4.1 ms ] story [ 133 ms ] threadI'm curious what the counter argument is...why do people want to do this? (edit: specifically why for blog posts and informational pages.)
Honestly I never understood this trend. From a developer side, the engineering easily costs two times compared to a traditional site.
There are so many "plain text" websites that simply do not load without JavaScript. Is this a consequence of using a framework like React? I feel like the world needs a "component-based" framework, but one that can gracefully degrade if JS isn't available.
It depends on how much JS is used and what it actually does. Sending and receiving data in a JSON format as opposed to receiving HTML? Could be marginally faster and would also allow integrating the API for fetching data with other front ends or other consumers easily.
What causes the actual slowdown most of the time is framework code which cannot have the unused bits removed efficiently because of how dynamic most of the languages that we use are, even if there are tree shaking advancements that you hear about every now and then.
That said, it's not entirely hopeless - you certainly can use something like react-snap to pre-render your site and then hydrate it with dynamic content and JS if supported by the user: https://web.dev/prerender-with-react-snap/
Of course, degradation won't necessarily be graceful - everything that depends on JS simply won't work, as opposed to have some theorethical server-side fallback component, as nice as that would be. I've also heard of server side rendered React, however, even though i haven't personally used it: https://www.digitalocean.com/community/tutorials/react-serve...
To be honest, trying to achieve such wide support for technologies and graceful fallback logic is a can of worms in of itself, so many simply choose to require JS functionality for their app and don't attempt to support other configurations, which is a shame.
Also, if your website just happens to have that one bit of information I care about, and I don't view other pages, rendering with Javascript is a complete waste.
[1]: https://svelte.dev/blog/svelte-3-rethinking-reactivity
At first.
But if you setup a lot of cool plugins with the newest bundler, add modern libraries and make good use of web workers and graphql, in a few months you can get your costs up to 5 or 6 times!
Wait, it makes it easier?
> But if you setup a lot [of libraries] ... in a few months you can get your costs up to 5 or 6 times!
Ah, lol!
But in all, SPA for SPAs makes sense, but for documents it's counterintuitive. I mean I can see a case where it might be worth it, but looking at Wikipedia maybe it's not justifiable for the increased maintenance.
Of course while the usual cause of rendering slowness in applications is emphasised (which is what I hear as a reason in favour of SPAs), but it tells me that your CSS isn't really optimized for your case.
If your backend only takes in requests and spits out data, you can build the backend without spending any thoughts on user experience, layout, templates etc. All you do is design a database structure and API endpoints.
Because you can then derived a good architecture from that, but never the other way around.
But UI means dealing with those messy humans, while the backend is this nice quiet place where you can whisper to orderly computers.
As a backend dev, my projects started to get way better once I learned to not start with the database model and start to test some mock up on users first. Yet it's so tempting...
Say the backend developer coded a bunch of Django views where they output json data. They say "Job done. There are API endpoints for everything now.".
Now how does the frontend developer bring their templates into play so the json gets rendered "on the server side"?
In a setup where the frontend is doing the rendering, you can give the frontend developer access to a directory with static assets that get output to the browser verbatim.
How do you give them the ability to "have a Django template filter" without them having the ability to mess with the rest of the backend? Or do you set up a second server that talks to the APIs of the first server?
But I don't think Django templates are safe in a way that they protect the backend from a clueless or malicious frontend developer. Even if they were, you would have to take great care that you do not expose dangerous functionality. So "give them access to the Django template itself" is not enough. You would have to have a whole security concept around it.
And that is not enough. How does the fronted dev create routes? How do they create views, which are the glue between the DB and the templates?
Node.js is a runtime, not a framework. It does not have routes, views or templates at all. So that comparison makes no sense.
No matter which backend framework you choose - you will have a lot more work to bring the frontend dev into the game if you do backend rendering.
Please be aware that I am not against backend rendering. I indeed think that backend rendering is the better approach! I just explain here why there is some appeal to developers to write the backend as an API and do the rendering on the frontend.
The idea is that you prepare the needed data in the "view," and then the template should be relatively dumb. If the template is causing any database/backend requests while rendering, that's generally a sign that you haven't put enough information into your view layer.
https://docs.djangoproject.com/en/3.2/ref/class-based-views/...
This pattern seems to have declined in popularity, but it can really win in speed and simplicity over a frontend/API split.
Many small blogs are hosted in servers with pre-configured static document sharing that won't let any server-side dynamic code run beyond "Fetch the static document at path X and echo it." In that context, you either need to run a framework that will assemble your dynamic page client-side, or you need to run a script that will pre-chew your blog from some more convenient format into a rich static HTML document and post it to the server.
A remarkable number of bloggers would consider that second option a bridge too far.
* Nothing to hack except the webserver
* Fewer moving parts to break
* Fast loading
* Cachable
* No Flash of unstyled content or other client rendering anomalies which people code around
* SEO crawling without JavaScript
Edit:
Javascript free static sites.
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.
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: https://idlewords.com/talks/website_obesity.htm
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.
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.
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.
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.
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'm curious why. For me, I've always been interested in keeping intellectually stimulated when I'm at work. I don't want impossible challenges but I want something that, while I'm working, time disappears so it doesn't feel like work.
Now, I did my fair share of server side rendering applications in the 2000s and enjoyed it at first. It was quite enjoyable to be able to pass my ideas and application around to others without the barriers of cross platform compatibility or security models that make running unknown or less known native binaries a no-no. This melted away with web applications (mostly, bar some pretty notable browser vulnerabilities during that era).
What happened really was Chrome's sandboxing and security overall that comforted many that running arbitrary JS code from an external source was "OK" because your browser was mostly protecting you from doing nasty things to your local system and data. This exploded into expanding JS, ES, and the entire development ecosystem.
To me, this is really what made things intriguing and I suspect why many love web development, they can easily share their creations now to about anyone without many barriers, just type in this address on your phone or laptop and tada.
Unfortunately, the development ecosystem is a mess. I don't think this says anything negative about classic application development, I love classic application development because it's usually well structured and I don't have to waste cognitive load dealing with silly technical issues I don't care about--I can focus on the application and what I want to create more. I don't want to know why this silly UI element isn't behaving the way it should and deal with a workaround, I just want a UI element that does this so I can move along and do the interesting work. What traditional application development really lacked was ease of portability for others to use securely.
The OS has now become the browser to many and this is their playground. Unfortunately I don't enjoy it because I'm used to mature frameworks where I don't worry so much about the application development as much, I worry about the application and translation of ideas into something people can use. Web development is getting there but it's just not there yet and if you've been spoiled with stable development environments it's hard to go back to the wild west of dealing with what you considered to be mostly solved problems decades ago.
I prefer programming in many other environments. I also greatly prefer not having to distribute anything to other computers.
The article is complaining not about the use of the Web to write/host apps, but about the unnecessary use of app-writing functionality (aka JS) to "enhance" documents or to reimplement browser document-reading functionality.
If you're writing an app, write an app.
If you're writing a news article, write a news article.
But browsers have not been improving their ability to serve documents.
Besides maybe initial load times (and fewer ads, whizzes, and pops), I get no significant benefit to reading an article with no JavaScript.
I don't get a searchable cache of my document history.
I don't get to swipe it over to some other device to continue reading without relying upon some other service.
I don't get some guarantee that the document will render on any device and that I can send the document to someone else without a url.
I can't highlight or add notes to a document or make corrections and view my (or others') versions of it.
Sure, they're documents, and so I should be able to treat them as such. But I can't. They're not portable. Browsers aren't really great for document management or manipulation. Static sites are just as tied to the browser and host as any app.
While I largely agree that dumb documents aren't that useful, I'd say a large part of our actual web interaction is still just dumb documents with some form of response (like what I'm doing here, or site comments, as others do). That's not to diminish actual applications which are made much easier by the web's distribution model, like Google Maps or Google Docs.
The web is absolutely document-first. Our applications are _still_ just documents, which is pretty incredible.
I just don't think it's very good at being document-first. A sufficiently advanced document-first platform would have a lot more functionality in regards to reading, modifying, maintaining, and sharing documents. As far as any consumer is concerned, a basic note-taking app provides more functional use than a web browser.
That may be the reason it's become better known as a kludged together application platform derived from layers upon layers of workarounds - around a substandard document viewer with amazing plugin support.
If I'm making any point at all, it's that I don't accept the premise of the original post. The web isn't as good at serving documents as we tend to say it is, but it's become quite the application platform, because everyone seems to want it to be one. So who cares if people make crappy pages using JS when it isn't ideal?
I've always framed it in terms of "where are the files?" Maximum control for the cool-making companies means "hide them from the users."
I'm really really really happy to see projects like obsidian.md that see the value in not doing that.
I'm also a fan of obsidian.md.
More seriously, I think I'm coming around to -- I don't care where or how the applications are made per se. I used to hate the web-stuff->desktop applications idea (electron et al) because it seemed dumb and slow, but both Discord and Obsidian disprove that pretty well I think.
It really is about "where is your stuff." It's fine to optionally store whatever in whoever's cloud. But increasingly, I believe that anyone developing any sort of application in which the user's stuff and how it moves around is not 100% transparent is quite literally evil and I wish them utter failure.
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.
Honestly for most sites, I just hit reader mode preemptively, especially on mobile.
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.
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.
As a consequence the web will be maybe a lot of faster and safer, too.
Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.
For comparison, consider that apple just proposed adding a html tag to display 3D models, just like an image.
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.
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.
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.
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.
Oh but that can't work because it's not really a document, but a dynamically laid out program after all.
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.
Also this series of pages was extremely popular on HN, and can't be done without programs embedded in documents:
https://ciechanow.ski/gears/
In this case it's done quite "literally" !
https://ciechanow.ski/js/gears.js
Although on closer reading the OP does make a distinction between documents embedding programs, and programs that build up documents (like medium.com), which I agree is an anti-pattern.
I don’t think it’s possible to anticipate exactly how everyone will want to use everything, but maybe we could reach a world where it’s easier to iterate on this.
For example, what if there was a way for the community to implement new HTML tags for their preferred browser? This could be implemented as an extension, though perhaps not under the dominant WebExtension paradigm. This would allow much faster iteration on the semantics of HTML within the secure sandbox provided by the browser. The IPFS extensions are a nice example of doing this at the protocol level.
Similarly, what if you could version HTML tags? That would be a bit of a nightmare, but would also allow authors to communicate more information to the browser about what functionality is expected from the tag.
Of course, this would lead to a strange ecosystem with many dependency management headaches for users. You’d have to worry about what new features were needed by the page you’re trying to view, which extensions you have installed, do they implement the tags you need, and do they do it well?
This would lead to “super extensions” that address many tags and become de facto requirements for everyone. Then those become security targets. Of course, they would have their own coordination process, parallel to W3C. This would become a business target just like W3C is, with google trying to manipulate it to liquidate user freedom to support advertising.
It’s hard to get big groups of people to work together effectively.
It’s hard to get big groups of people to work together effectively.
One of the valid ways to deal with it is to let them work separately.
"apt install myapp" works 95-99% of the time. The remaining time, you drop yourself into DLL hell of some flavor or other (package was poorly maintained, or your clone of the package repo indices is out of date, or you installed a local copy built-from-scratch of one of the binaries and it's now fighting with the distro binary, &c &c). And then remote tech support is impossible because for someone to provide support, they either need intimate knowledge of your configuration or you need to be running a stock configuration (and with very few, usually vendor-controlled exceptions, "stock configuration of a Linux distro" is a non-concept).
There was, ages ago, a paper describing what the design of a componentized browser rendering engine would look like (where pages could basically declare "I require engine components X, Y, Z" and the browser would have a library of them that could be spun up on a page-by-page basis). I wish I could grab a link to it; I think it may have been a Mozilla experiment? If I recall correctly, the complexity meant it never gained traction.
It was novel at the time, and we have something like that today in the form of the web browser... Though most data one fetches isn't intended for in-place editing, the convenient thing about web pages is that their hierarchical, dynamic, and self-modifying nature allow for a lot of the concepts explored in OpenDoc and OLE to be implemented within them.
> 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.
> Oh but that can't work because it's not really a document, but a dynamically laid out program after all.
What prevents one from sending a screen size and getting a server-side rendered SVG back with that exact screen size? It was a thing in Telnet days, and it's what Stadia/Mighty browser are doing. Not that I'm saying it's a good idea, but it is feasible.
But it would be better if the application functionality of Google Maps was part of the document viewer (or selectable from within the document viewer), not of the document, because that gives you the flexibility to use your map viewer of choice, instead of being bound to Google Maps. That’s the point of separating document from viewer (and/or editor). Turning everything into an app reduces choices and interoperability.
> Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.
I would argue that websites would be better off embedding an image of the location that links to a dedicated map viewing service like OpenStreetMap.
I might be in the minority here, but I always hate trying to use interactive maps in tiny boxes on people's websites.
OP linked two websites as bad examples... and they both totally work, so what?
"You can even run into serious security flaws" prove it, hack it.
"you get compatibility issues" worked for me
"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.
This took me around 20 seconds to find, but I think I'll stop there :)
It's also similarly broken on my web browser. Maybe I have to pick up IE5.5 ? I ponder if that was the point .
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?
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.
I mean, Mosaic added forms in 1993. [1]
[1] : https://www.w3.org/People/Raggett/book4/ch02.html
OP addresses this point well in my opinion:
> If your page includes a few non-essential scripts to do different things on the page, that isn't a problem. The document itself is still readable in a wide variety of programs and formats, regardless of support for those scripts.
If your post is still readable without JS, no one complains if the comments don't work. And no one complains, if you implement comments using JS.
The problem is, if the core content is actually a document, but behaves like an app (and you cannot access simple text because you disabled JS).
My core issue was around this and I should have sticked to it :
> The original purpose of the Web was to be a set of protocols and formats used for the purpose of publishing documents.
I still think this is a bad argument, I disagree that HTML was conceived as a way to make "documents", but it shouldn't matter, things evolve on their own and people may use your creation in ways you disagree with.
> The problem is, if the core content is actually a document, but behaves like an app (and you cannot access simple text because you disabled JS).
I 100% agree with you, but the distinction is the "core content" part.
Part of the page is that core content, and what we actually want to see/read indeed (and why various web browser brought a "reader mode" that extracts that part). But the page itself is not a document that only contains this core content, and hasn't been for a couple of decades.
Most blogs/publication, even personal ones have been backed by a publishing system with the core content in a database. At this point these are applications, and many of these system can still output "pages" that 100% fit the description of being easily readable without JS, while still adding a lot of utility. Hence my disagreement around the "Documents ≠ Programs".
That's the distinction I was trying to make.
> It can be very useful to run certain programs in the browser. In a lot of cases, however, the same technologies are used for documents.
And yes, often the HTML is generated from a database. That's fine. "Document" does not equal "file on disk". The HTTP/HTML model just talks about the entities that actually hit the wire. If what you're delivering to the browser isn't a document, but rather a program running in the browser to build a document, you should be taking a deep breath and checking whether you actually need to do that.
A blog should be readable everywhere, even in lynx. Interactive, discoverable documents and multimedia content should include a text fallback if possible. And real apps like a photo editor -- well they need to be executed.
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.
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.
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.
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.
Static sites are better for those who don't want to enable JavaScript or who would like to save a copy of the page to read later. I'm sure there are accessibility benefits with less complicated websites, too.
Maybe I'm just strange, though. I log in directly to a TTY.
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.
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.
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.
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.
The first, in the linked post, states
> It’s massively over-engineered! But that’s the point: learn, have fun and enjoy slowly hacking away after the kids go to bed.
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 agrees -- it's just that the fun and learning make it worth it.
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.'"
Well, one reason why it might have been done suboptimally is that the creator is a college student (https://slc.is/#About). Nobody learn in public where this guy might find it, I guess, or you're an 'idiot'.
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.
There's nothing wrong with learning, of course. My point was that if you choose to introduce this unnecessary complexity you will likely end up with an unreliable website that alienates some visitors.
Most personal websites are made for the creator themselves more than they are for others, mine included. With computers, you should do what makes you smile. On the other hand, publishing something on the internet opens yourself up to criticism by others. There's definitely a lot of problems with my website, I invite you to write about it.
https://gemini.circumlunar.space/
Another thing I disagree with:
> On-the-fly "building" of documents is, quite literally, fixing something that is not broken.
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).