Comment by 1dom
5 days ago
I think this is silly, and it's a hill I'm willing to die on. I wrote this in a comment yesterday, and Jeff has fully confirmed/vindicated this in his post:
SSGs are good for static sites with no interactivity or feedback. If you want interactivity or feedback, someone (you or a 3rd party service provider) is going to have to run a server.
If you're running a server anyway, it seems trivial to serve content dynamically generated from markdown - all an SSG pipeline adds is more dependencies and stuff to break.
I know there's a fair few big nerd blogs powered by static sites, but when you really consider the full stack and frequency of work that's being done or the number of 3rd party external services they're having to depend on, they'd have been better by many metrics if the nerds had just written themselves a custom backend from the start.
Jeff: I think you'll regret this. I think you'll waste 5 - 10 years trying to shoehorn in basic interactivity like comments, and land on a compromised solution.
I also used and managed Drupal and Joomla before I went to SSGs, and then finally realised there's a sensible midpoint for the pain you're feeling: you write/run a simple server that dynamically compiles your markdown - good ol' SSR. It's significantly lighter, cheaper and easier than drupal, and lets you keep all the flexibility and features you need a server for. Don't take cave to the "self hosted tech was too hard so I took the easy route that forces me to also use 3rd party services instead" option.
SSGing your personal site is the first step to handing it over to 3rd party services entirely IMO.
> If you're running a server anyway, it seems trivial to serve content dynamically generated from markdown.
Until you have enough visitors or evil AI bots scraping your site so that it crashes, or if you're using an auto-scaling provider, costs you real money.
The problem isn't in markdown→HTML conversion (which is pretty fast), it's that it's a first step in adding more bells and whistles, and before you know it, you're running a nextjs blog which requires server-side nodejs daemon so that your light/dark theme switch works as copy-pasted from stackoverflow.
For blogs, number of reads vs number of comments or other actions that require a server is probably on the order of 100:1 or 1000:1, even more if many of the page loads are bots/scrapers.
> SSGing your personal site is the first step to handing it over to 3rd party services entirely IMO.
Why? Your interactive/feedback parts can be a 10-line script as well, running on the same site where you'd run Drupal, Joomla, Wordpress, Django, or whatever.
Looks like Jeff plans to do exactly that: https://github.com/geerlingguy/jeffgeerling-com/issues/167
> Until you have enough visitors or evil AI bots scraping your site so that it crashes, or if you're using an auto-scaling provider, costs you real money.
There's been multiple blog posts on HN from people who've received a hug of death and handled it fine with basically free or <$10 /month VMs
A couple of gigs of RAM and 2 cores can take viral posts and the associated bots. 99% of personal websites never go viral either.
> The problem isn't in markdown→HTML conversion (which is pretty fast), it's that it's a first step in adding more bells and whistles, and before you know it, you're running a nextjs blog which requires server-side nodejs daemon so that your light/dark theme switch works as copy-pasted from stackoverflow.
This is my exact argument against SSGs, and Jeffs post proves it: it's easy to use SSG to generate web pages, but the moment you want comments, or any other bells and whistles, you do what Jeff's going to have to do and say you'll do it later because there's no obvious easy solution that doesn't work against and SSG.
> Why? Your interactive/feedback parts can be a 10-line script as well, running on the same site where you'd run Drupal, Joomla, Wordpress, Django, or whatever.
EXACTLY! This is my point! Why not just SSR the markdown on the server you're already running?!
This is the opposite of what Jeff and 99% of other SSG users do, they switch to SSGs to get rid of dealing with servers, only to realise they need servers or third parties, but then they're sunk-cost-fallacied into their SSG by the time they realise.
You seem to think an SSG is some burden that people put up with due to sunk cost fallacy, but I don't see why.
The Markdown-to-templated-HTML pipeline code is the same whether it runs on each request or on content changes, so why not choose the one that's more efficient? Serving static HTML also means that the actually important part of my personal webpage (almost) never breaks when I'm not looking.
1 reply →
How many RPS is a hug of death?
1 reply →
I'm already self hosting my own cookieless analytics, and before, I hosted Drupal (LEMP stack) and Apache Solr on separate servers. I'm used to self-hosting, and any comment solution I use will be self-hosted as well (see: https://github.com/geerlingguy/jeffgeerling-com/issues/167)
The code surface with SSG + 1 or 2 small self-hosted OSS tools is much, much smaller than it ever was running Drupal or another CMS.
Yes, SSG pipeline + 1 or 2 small self-hosted OSS tools is way simpler than Drupal.
But all you've done in bought on all the pain and compromise of having to think from an SSG perspective, and that created problems which you've already identified you'll figure out in future
I'm suggesting 2 or 3 small self-hosted OSS tools, where one is a small hand crafted server that basically takes a markdown file, renders it, and serves it as plain HTML with a header/footer.
This is more homogenous, fewer unique parts/processes, and doesn't have the constraint of dealing with an SSG.
I remember my own personal pain from 2010 - 2016ish of managing Drupal and Joomla. I did exactly the same as you in 2016 and went all in on SSGs and in 2024, I realised all of the above. I feel like I wasted years of potential development time reinventing basic personal website features to try and work with an SSG and you literally have a ticket to do just that: https://github.com/geerlingguy/jeffgeerling-com/issues/167. 1 of your 3 solutions involves letting someone else host your comments:(
A custom framework/server is the end destination for all nerdy personal websites - I can't wait to see what you make when you realise this:)
edit/p.s. I love you and all your work. Sorry for sounding disagreeable, I'm excited to see what you learn from you SSG journey, I hope you prove me wrong!
Definitely not disagreeable, more just "there are two right answers" ;)
For me, an unstated reason for SSG is being able to scale to millions of requests per hour without scaling up my server to match.
Serving static HTML is insanely easy, even on a cheap $5-10/month VPS. Serving anything dynamic at all is an order of magnitude harder.
Though... I've been using Cloudflare since 2022, after I started getting regular targeted DDoSes (was fun initially, seeing someone target different parts of Drupal, until I just locked down everything except for the final comment pages). The site will randomly get 1-2 million requests in a few minutes, and now Cloudflare eats those quickly, instead of my VPS getting locked up.
Ideally, I'll be able to host without Cloudflare in front at some point, but every month, because of one or two attacks, the site's using 25-35 TB of bandwidth (at least according to CF).
3 replies →
But how in the world will you shove a decent search into a static site?
I really want to know because there is a Drupal 7 site that I need to migrate to something but I need good search on it (I’m using solr now).
Edit: I should have specified that I need more functionality than just word searching. I need filtering (ie faceted search) too. I’ve used a SSG that uses a JavaScript index and appreciate it, but that’s not going to cut it for this project.
The usual way is to create an index on generation time and serve it statically. JS just uses the index to do the search. It's a big file, so I'm not saying it's a great solution for everyone, but it works reasonably well.
Of course, for my site I just redirect the user to a search engine plus `site:stavros.io`.
See https://gohugo.io/tools/search/. Not sure how well they scale to thousands of posts, but they work by statically generating multiple static search index files at build time that are queried via client JavaScript when hosted. The search UX is actually really good because they tend to respond instantly as you type your query and allow complex queries.
15 replies →
> there is a Drupal 7 site that I need to migrate to something
You may be interested in Backdrop, which is a maintained fork of Drupal 7.
https://backdropcms.org/
(No experience with it personally. Only know about it from a friend who uses it.)
> all an SSG pipeline adds is more dependencies and stuff to break.
This is the exact opposite of what static site generation does.
Not if you're already running servers and server applications. If you already have patterns for running and deploying server software, an SSG requires an extra preprocessing step to generate the HTML for the server.
If you don't use an SSG, this step is done by virtue of the server running.
Shoehorn basic interactivity like comments?
https://gohugo.io/content-management/comments/
This includes a giant list of open source commenting systems.
I really don’t understand why people commonly say static site generators are a good candidate for building your own when there are a good selection of popular, stable options.
The only thing I don’t like about Hugo is the experience of using other people’s themes.
https://cthor.me/SSG
Getting someone else's SSG to do exactly what you want (and nothing more) takes longer than just building it yourself. Juice isn't worth the squeeze.
I disagree with your take there.
> It took me a weekend to write the initial Perl script that made this site. It took me another weekend to do the Rust rewrite (although porting all the content took two weeks). These are not complicated programs.
My last Hugo site took 30 minutes to deploy, not a whole weekend. Picked a theme, pasted in content.
> You want free web hosting? Hugo might be the right option.
An extremely good reason to pick Hugo especially if you don’t have the know-how to build your own SSG. You don’t need to know a programming language at all to use it.
Again, I have to throw criticism toward this idea that everyone who wants a static site generator already has the skills required to make one.
And I’m not saying it covers every use case like the kind of person who is willing to pay $100+ per year on a full blown solution like Shopify and Squarespace. It fits a niche: someone who wants their content online without coding with no hosting cost and doesn’t want to rely on third party platforms like Substack.
Pretty much every single option there involved letting a 3rd party collect and own the comments.
If you're fine for 3rd parties to own all your comments and content, why even take on the extra effort of hosting or managing or building your own website? That's basically what social media is for.
What do you mean? The list has more open source options than not. You can self-host those.
It’s going to be easier to self-host a drop-in comment system than an entire dynamic site plus/including comment system.
2 replies →
> SSGs are good for static sites with no interactivity or feedback. If you want interactivity or feedback, someone (you or a 3rd party service provider) is going to have to run a server.
For my website, I do both. Static HTML pages are generated with a static site generator. Comments are accepted using a server-side program I have written using Common Lisp and Hunchentoot.
How did you get to that position? Did you have to create the server side components to solve the SSG comments problem...?
I have always had a comments section on my website since its early days. Originally, my website was written as a set of PHP pages. Back then, I had a PHP page that served as the comment form. So later when I switched to Common Lisp, I rewrote the comment form in it.
It's a single, self-contained server side program that fits in a single file [1]. It runs as a service [2] on the web server [2], serves the comment and subscriber forms, accepts the form submissions and writes them to text files on the web server.
[1] https://github.com/susam/susam.net/blob/0.4.0/form.lisp
[2] https://github.com/susam/susam.net/blob/0.4.0/etc/form.servi...
[3] https://github.com/susam/susam.net/blob/0.4.0/etc/nginx/http...
6 replies →
I converted my site to an SSG site and have never regretted it. Then again, I find that the less interactivity, the better.
I think you're the tiny minority of people who have a bright future ahead with SSGs.
Anyone who wants/needs interactivity is digging themselves into a hole.
I started writing a blog engine back when I was in college. I've been working on it ever since, and it's let me implement and play with cool web features. I implemented Markdown over 10 years ago, and I don't regret it. The Markdown is converted to HTML once on save.
It's supported RSS since practically the beginning, and RSS later served as a foundation for a backup and restore system. A few years ago, I implemented SSG functionality (exports html, css, images, etc in a zip).
https://github.com/theandrewbailey/gram
Yes, SSGs are like a one-way street. Once you drive into one it is very hard to back out and make your website more dynamic.
However, some people like building websites and are fine with that. Plus, it allows you to write another blog post :)
This is where I've found Astro to really shine. Most people reached for it because of the whole "islands of interactivity" concept, but IMO the ability to easily build a mostly static site with server APIs when needed is a the killer feature.
I manage multiple Astro sites and eventually they have all needed at least a few small server endpoints. Doing that with Astro is very simple and it can be done without making the static portions of the site a pain to maintain.
Ive reposted my personal demo Astro project with zero eyes
Is anyone willing to give feedback on it whatsoever?
https://tariqdude.github.io/Github-Pages-Project-v1/visual-s...
Just a small note - I see a lot of warnings about "Long Tasks" in the dev console log (Chromium) - likely related to the animation which is jittering on my Mac M1.
I have a vague memory that one of the largest commenting sites on the internet, 4chan, was basically statically generated.
Every time a comment was added, it just generated a full-ass static web page.
I run an e-commerce website on Hugo. The only non-static part is a short Python function I run in a cloud to forward the orders to Stripe.
But what about Disqus? Or that one that renders comments from GitHub Issues?
Disqus shows a lot of ads these days.