I was recently asked Why a static site generator? Especially since I can work fairly well with Django. So, fair question.

When I start programming something that I want, I'm not in "professional programming" mode, but instead in exploratory mode. That, too, is something I talked about in the podcast. This means that I rarely plan ahead for very long, instead I try to reach concrete goals as simply as possible. You know, "agile".
This means that I don't care so much about doing it "right", but instead about doing it "fast". So here's the first answer to the question: When I was re-doing my blogAgain, this was the simplest way to do it. I had already had a static site generator that didn't do what I wantedOr rather, that I couldn't get to do what I wanted. Failure here is my own, not that of the software. so I replaced it with a different SSG: mine.
And that is perfectly fine for exploring and learning new programming stuff. I'm doing this for my entertainment, after all.

But there is a more general answer to the question "why static site generation", and like all software development, there are trade-offs to be made. The short summary is this: * minus: I'm not an expert * minus: less library support during development * minus: no dynamic user interface * minus: no dynamic content * plus: exact points in time for updates * plus: simple hosting * plus: more security (due to simple hosting) * plus: fast responses (due to simple hosting)

Let's take them one after the other.

I'm not an expert.

This is mainly a minus, apart from the exploratory/learning angle I mentioned before. But in general, one should try to do things that one is good at, because the expected result is better. With this, my first instict of course was to do something in Django. I know Django, and I'm very good with it. So I know that I could to this, and I could do it well.

But it's also kind of boring: another CMS, yay. So not exactly the greatest thing to do in my less-than-reams-of spare time.

So in my situation, the "new thing"-angle was more important. But this is something that you need to be aware of when designing a software solution: are you doing this because you know what to do, or because it's new and shiny and different, or because it's the best fit? In a professional setting, one should always go for the best fit.

Less library support during development

Let's face it: there are many libraries in many languages that allow you to do dynamic web applications. It's an interesting space and some of the solutions are absolutely fantastic. So one thing you can do is just choose one, follow the tutorials or your expertise and create something excellent.

Great!

The library situation for static site generation is... uh... sparse. I don't know of any. Didn't search either, but I wouldn't even know what to search for. So, there's much less guidance when creating an SSG instead of a dynamic web site.

And this is an important point: while it's often great fun to do something different, it's not always advisable. There are good reasons for the prevalence of dynamic web sites, and you should choose the right technical architecture for the problem you're solving.

No dynamic user interface

This is kind-of obvious. A static site will not have a dynamic user interface. No admin interface. No forms. No built-in way to see and edit the content.

If you need that, you need to find a different solution. Either by going fully dynamic, or maybe a sort-of hybrid solution with a dynamic editing interace and then a static siteHere are two options: Wagtail Bakery, Lektor.

No dynamic content

This is the most obvious difference between a static site and a dynamic site. One is fixed and doesn't change, the other is dynamic and can change on every request.

In case you might have missed this: that's the point about dynamic web sites. They are dynamic, d'uh!

And if you need dynamic content, that's really about the only thing you can do. Have a database, store your data there, build the site "on the fly" when someone requests it. Fine!

But do you really need it? Sometimes you might not need it.

Exact points in time for updates

You know that one of the hardest problems in computer science is cache invalidation. So with a dynamic site you go full in one direction: no cache at all, so nothing to invalidate. Easy and always fresh!

But that's usually not enough. In one of my first commercial projects we had to interact with an API that would give us product prices. Since we had about 20 products per page, we'd have to call the API 20 times, and that was just too slow. So what did we do? Yes, we stored the prices in our own memory, in a memcached. Super-fast, but: how long are you supposed to keep these prices? At what point in time do you renew them? What about products going out of stock. We needed some cache invalidation and, honestly, that was the hardest thing about the entire project.

This is a rather more general process: you have a dynamic site, it's too slow, you put some caching in front of it (the Django cache, a memcached, squid, etc), doneSee how many cache servers you can spot in the Wikipedia server infrastructure!! But, not really! Now you need to keep your caches fresh. You want your content to respond dynamically, that's the point of your site, so you must make sure that the caches aren't stale. And thus, cache invalidation.

But what if you look at the problem from the other side. What if you start not from a continually changing site and delete cached content that has changed, but instead start from a constant, unchanging site and add singular points in time when the content can change. So whenever some content changes, you push the change into the site, instead of pulling from a dynamic data set into your cache.

And thus, static site generation. I have a set of data (in the form of markdown files, but could be anything), and whenever I am happy with the state that they're inI mean, except when I make a mistake and publish a draft., I regenerate everything and push it live.

There are now exactly-defined points in time when my site changes, and that fits my use case perfectly.

Simple hosting

Not having to regenerate the site whenever it is requested also makes serving the site much simpler. There's a directory of files, go serve that. Any webserver can do that. No need for complex infrastructure, reverse proxying, app server, database, media and static serving; just simple, easy file hosting.

Heck, it's so simple, you could put it on an S3 bucket and call it a day.

Heck, it's so simple, Github will do it for you for free!

With simple hosting come other benefits. You don't need to worry about someone breaching your database because there is no database. Remove all nginx plugins and you'll have a digital fortress as secure as it can be.

And it'll be fast, too. Simple file serving is fast on its own, but if it's not fast enough, put your site on a ramdisk and you'll saturate all the networks you have. My fully generated site is about 12MB large. I can afford that much ramdisk.

in Summary

Look, I just wanted to do this, ok? It works for me, and I'm having fun.

Are there more reasons needed?