Comment by raddan
8 days ago
I understand that somebody might want to generate static pages from code that generates it dynamically, but I fail to appreciate _why_. Are people using this for a handful of pages they want to load quickly and whose contents rarely change, or are people building entire static sites using things like React? If it's the latter... uh... why? It's been awhile since I was a web developer, so maybe my pain threshold is inappropriately low. I think Jekyll is fine and use it pretty regularly.
It's because inevitably there comes a time where you want some pages (or even sub-pages) to be static, and other pages (or parts) of your application to be dynamic. If the question is "why" the inverse is "why not"?
Dan's blog is rendered as static, works without javascript and still lets him write complex client-side components when he calls for it. And if one day he decides to add a page that renders content dynamically, he can do so in the same patterns and framework that he's already using.
The goal is developer-choice. No need to pick static or dynamic holistically, have access to both when you need them. No need to pick between hydrating the entire website vs. rendering exclusively on the server. No need to pick between writing client-side amenable code or server-only code.
How many platforms have a "marketing" website for / and a platform website for /dashboard? No need to split them, just use a framework that accommodates both seamlessly. It's more powerful, even though it does come with a learning curve.
To give a concrete example, I’ll probably add some dynamic stuff at some point in the future, like commenting with Bluesky or such. It’s nice not to switch tools for that.
It is certainly not true that the point you describe is inevitable. Lots of sites will never reach the point where they need dynamic content. As to "why not" - because simplest is best until such time as you have a genuine need for the complexity. YAGNI is a maxim for a reason.
Really feels like this generation of devs do not see the value in YAGNI, mostly appear to chase complexity because that's how you peddle courses, talks, books, etc.
I think the reason to split the marketing page from the dashboard one is that you can deploy one without the other. I would actually prefer to have all the marketing stuff in its own repo away from any dashboard code.
As someone who uses Astro a lot for (mostly) static pages, the two standout features of this approach that come to my mind are code sharing and the ease of integrating SSR/CSR where needed.
Components (be it Astro, Svelte, React, etc.) have a lovely API for sharing code across web pages. I used Hugo before and hit the limits of shortcodes pretty quickly. I can't comment on Jekyll though.
Furthermore, if the need for some dynamically rendered pages or client-side interactivity comes up, it is very easy to integrate this later on. I can build static, server-rendered and client-rendered pages (and everything in between) with the same set of tools, which means less mental load when I develop.
Nowadays it’s common for things to not be entirely static but kind of a mix. Some interactive client stuff, some dynamic server stuff. It’s nice to stay within the same programming model for these.
React might sound like a weird choice to you but its composition model including server and static stuff is quite powerful. See here for a slightly contrived but representative example: https://overreacted.io/impossible-components/#a-sortable-lis...
Mainly because they all discovered that fully dynamic client-side SPAs written in 100% JS are extremely slow, and wanted a way to speed them up whilst keeping most of the developer experience of an SPA.
That's it. It's not a clever way to arrive at the conclusion that the server is useful, but they got there in the end.
Because most mainstream frameworks are too bloated to handle more than a few hundred rps on a normal server, and caching has gone out of fashion (?), so it's the best way to save money.
All of this makes very little sense, but every couple years a guru will shout new commandments from his social media mountaintop and reshape the landscape. It's more of a religious ritual at this point, really.
On a more serious note, it's also because the market is saturated with developers who specialize on React, and this is what's easy and makes sense to reuse their knowledge and code (vs say, setting up a caching reverse proxy and dealing with invalidation).
I’m actually quite excited for caching to make a comeback: https://overreacted.io/functional-html/#caching
Although I don't usually use react, for me, there is a certain joy and also efficiency that comes from using some of the abstractions that you got from the larger JavaScript/web ecosystem while also having the ability render all that magic to a folder with a couple of HTML, CSS and JavaScript files.
With LLMs to help wrestle the boilerplate, I've found I can whip up a fast static site using advanced ergonomic abstractions that make the whole process a joy! In the past, wrestling the Node and NPM ecosystem was a a complete nightmare. Now it's, a dream — with the occasional storm cloud.
This makes perfect sense for a headless CMS. An editor might upload changes or a new article a few times per day/week into a database through a headless CMS. A webserver could make a request to the headless CMS/database for every web page load, but if the content doesn't change then the webpage can be computed and served statically. The web server can compute just the changes per page or regenerate the whole site on any change on the backend.
You can also simply call it caching and put that rendered html in cache inside or even outside your system and you get the same thing.
Because it's an easy and widely used framework to write JavaScript components that react to changes in state
Jekyll is fine. So is React. And Astro. Some folks like different things than others.
[dead]
[dead]