Comment by 1dom
6 days ago
Thanks for the considered response, I do really appreciate your time responding, I'm hyper aware my position feels controversial and at odds with people like you and Jeff for whom I have immense respect for.
Your post boils down to "I evolved into this form problems I had in the 2010 - 2020 period".
> There were some practical benefits too. In some tests I ran on a cheap Linode VM back in 2010, a dynamic PHP website could serve about 4000 requests per second before clients began to experience delays, while Nginx serving static files handled roughly 12000 requests per second. That difference is irrelevant day to day, but it matters during DDoS attacks, which I have experienced a few times. Static files let me set higher rate limits than I could if HTML were computed on demand. Caching could mitigate this too, but again, that adds more moving parts. Since Nginx performs extremely well with static files, I have been able to avoid caching altogether.
I really appreciate this explanation. It mirrors my experiences. But it's literally saying you did it for performance reasons at the time, and that doesn't matter now. You then say it allowed you to avoid caching, and that's a success because caching is extra moving parts which you want to avoid.
The SSG is an extra moving part, and it basically is a cache, just at the origin rather than the boundary.
Portability is a good point. My preferred/suggested alternative to SSG is dynamic rendering and serving of markdown content, and that gives me the same portability. Most markdown editors now respect certain formats of relative wiki links.
> Static site generation is simply another acceptable solution; one that I enjoy working with.
You are right. Fun is the primary reason why I'm being so vocal about this, because I spent 5 - 10 years saying and thinking and feeling all the things SSG advocates are saying and thinking and feeling about SSGs. I spent a few years with Jekyll, then Hugo, a brief stint with 11ty, and also Quartz. But when I wanted to start from scratch and did a modern, frank, practical analysis for greenfielding from a bunch of markdown files last year, I realised SSGs don't make sense for 99% of sites, but are recommended to 99% of people. If you already build, run and maintain a server side, SSG is just an extra step which complicates interactivity.
Having said all that, I don't really share my stuff or get any traffic though, so whilst I might be having fun, you and Jeff both have the benefit of modern battle testing of your solutions! My staging subdomain is currently running a handcrafted SSR markdown renderer. I've been having fun combining it with fedify to make my stuff accessible over ActivityPub using the same markdown files as the source of truth. It might not work well or at all (I don't even use Mastodon or similar) but it's so, so much fun to mess around with compared to SSG stuff. If fun coding is your motivator, you should definitely at least entertain the throw-out-the-SSG way of thinking, y'know, for fun:)
> I'm hyper aware my position feels controversial and at odds with people like you and Jeff for whom I have immense respect for.
Thank you for the kind words. I don't find your position to be controversial at all. Preferring a server-side solution to serve a website, especially when one is going to do server-side programming for interactivity anyway, sounds like a perfectly reasonable position to me. If anything, I think it is my preference for two different approaches for the content and the comment forms that requires some defence and that's what I attempted in my previous commment.
> But it's literally saying you did it for performance reasons at the time, and that doesn't matter now.
Actually, it still matters today because it's hard to know when the next DDoS attack might come.
> The SSG is an extra moving part, and it basically is a cache, just at the origin rather than the boundary.
I agree and I think that is a very nice way to put it. I realise that the 'fewer moving parts, not more' argument I offered earlier is incorrect. You are right that I am willing to incur the cost of an SSG as an additional moving part while being less willing to add a caching layer as an additional moving part. So in the end it really does come down to personal preferences. The SSG happens to be a moving part I enjoy and like using for some of the benefits (serverless local browsing, easy mirroring, etc.) I mentioned in my earlier comment. While mentioning those benefits, I also acknowledged that there are perfectly good non-SSG ways of attaining the same benefits too.
> My preferred/suggested alternative to SSG is dynamic rendering and serving of markdown content, and that gives me the same portability. Most markdown editors now respect certain formats of relative wiki links.
Yes, sounds like a good solution to me.
> If you already build, run and maintain a server side, SSG is just an extra step which complicates interactivity.
Yes, I agree with this as well. For me personally, the server-side program that runs the comment form feels like a burden. But I keep it because I do find value in the exchanges that happen in the comments. I have occasionally received good feedback and corrections there. Sometimes commenters share their own insights and knowledge which has helped me learn new things. So I keep the comments around. While some people might prefer one consolidated moving part, such as a server-side program that both generates the pages on demand and handles interactivity, I lean the other way. I prefer an SSG and then reluctantly incur an additional moving part in the form of a server-side program to handle comment forms. Since I lean towards the SSG approach, I have restricted the scope of server-side programming to comment forms only.
> If fun coding is your motivator, you should definitely at least entertain the throw-out-the-SSG way of thinking, y'know, for fun :)
I certainly do entertain it. I hope I have not given the impression that I am recommending SSGs to others. In threads like this, I am simply sharing my experience of how I approach these problems, not suggesting that my solution is better than anyone else's. Running a personal website is a labour of love and passion, and my intention here is to share that love for this hobby. The solution I have chosen is just one solution. It works for me and suits my preferences but I do not mean to imply that it is superior to other approaches. There are certainly other equally good, and in many cases better, solutions.