Comment by switz
8 days ago
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.