The Downsides of a Static Site Generator – Drinking Caffeine

Martyn Chamberlin:

On the whole, the cons of a static file generator seem less tangible than the pros

This is a topic I’m a little obsessed with. I struggle with static-vs-CMS on a regular basis. Martyn makes good points, but also a few that make less sense to me. Each of his points favoring static site generators are spot on, although just saying they’re “geekier” would be enough. No need to blame it on ego.

It’s the downsides that I have some issues with.

Database-driven design gives you better flexibility

I’d say it gives you different flexibility. Some of the things done using a database come easily for us ego-driven nerds using text files and our favorite editor. The SSG handles most of the rest.

Every time you do a new deploy in a file-driven system, you have to rebuild the entire website

That’s true. On the other hand, with a WordPress site you have to rebuild each page every time it’s requested ¹.

Yes, there’s a slight performance cost to increasing the number of rows in the wp_posts table, but it’s infinitesimal compared to increasing the file count in a file-driven system

Re-rendering my entire 3000+ page Hugo site takes about 2 seconds, so I don’t agree with this one. “Infinitesimal” seems a bit of an exaggeration, at least. I don’t feel at all like I’m slowing anything down by adding new static posts to Hugo. And again, any performance hit is once-per-deployment rather than once-per-view.

Related, every time you write a new post in Hugo, you’re creating a new file in a flat directory. Pretty soon you have hundreds or thousands of files

Yep. I have thousands of small, easily manageable, storable, backup-able, versionable text files in whatever directory structure I want on my own machine. So soothing!

WordPress has 28% of the global market. How much does Jekyll have? How much does Hugo have? A lot less than that.

True. The ecosystem around a product is important. There are two parts of the longevity consideration: How long the platform is available, and how long the content is available. He misses the second part here. I’m convinced that the odds of my content being available as a static site in 40 years is higher than if I were running it with WordPress. And even the platform availability matters less with a static generator, as I expect to be able to render static Markdown files using something for the foreseeable future. Still, he’s right about the ecosystem. WordPress offers a ton of resources.

It’s harder to get Go compiled and running than PHP and MySQL, simply because PHP and MySQL are more popular

I don’t understand this one, since you don’t even need to have Go installed to use Hugo. Hugo is a self-contained, pre-compiled binary with basically zero dependencies. Jekyll is a different story, but for some reason he didn’t use that in his example.

Getting your content from WordPress is a lot easier than from Jekyll or Hugo. That’s because it’s easier to get importable data out of a database than it is from a collection of markdown files.

I don’t understand this one either. I don’t have to “get my content” from Hugo. I already have it, no? It’s more like I have to put my content into Hugo than get it out.

Anyway, I’m not trying to pick on the article, really. I struggle with these same issues so I’m just using it as a way to think things through.

I run both static sites (Hugo and Blot) and CMS-managed sites (WordPress and SquareSpace). Both have merits, which is why I can never pick just one!

For me it tends to come down to convenience. I find WordPress more convenient to publish with. Click…type…click…done. The decision is harder with longer, more text-heavy writing, but I frequently post short pieces containing images and there’s no contest there. Drag a photo into WordPress and everything is taken care of for me. Some UIs for SSGs are starting to make this easier, though.

With a SSG, there’s more distance between the writing and the results (although Blot comes close here). See WordPress is a Typewriter.

Other things I think about…

Backups are pretty easy both ways. I don’t worry about losing content due to a database. Anything longer than a paragraph is usually written locally as text first, so I always have that copy. I also run httrack occasionally (gives me a static version of my entire WP site) and export everything occasionally to XML or whatever. That last bit is beyond what “regular” people are likely to do, but for me it works.

For me the biggest difference is on the hosting side. Static sites can just be dropped anywhere and will be fast, secure, and easy. WordPress is, while not difficult, more of a pain to host. It’s also prone to security and performance issues.

With all that said, I’m typing this in MarsEdit for posting to my WordPress blog. So there’s that.

Previously, previously, previously, previously, previously.