The down side of Static Site Generators

It's been nearly a year since I looked at the benefits of a static site generator, which I followed up with some PHP based generators which used Twig templating. I've since started a new mini-blog (details to come later) where I settled on using a static site generator (SSG) to get high performance out of low resource hardware.

It works great. The pages load really quickly, but then there's not a lot to show at the moment. It's a little bit of text with, currently, no images. There's no database to show things down, and no massive JavaScript overhead to impact rendering performance. It literally serves HTML files of the posts, with a little bit of CSS to make it look reasonable (I'm not going to claim it is pretty).

I have found a an issue with static site generators which I hadn't considered before. The lack of a CMS means it's not as simple to manage draft posts. With a CMS you can log in from anywhere and start creating content (like this). So long as you can connect to the CMS, you can start creating content. Then, when you log in from a different location or on another device, your draft is there.

With a SSG, you need a different way of managing drafts. All of the posts are built from content within the generator itself, which isn't usually something you can access from anywhere.

There's also the risk that by adding a new draft post in the static site generator that you will re-build the site for a new post, or a theme update, and end up publishing an unfinished article.

To get round that, you may end up creating different drafts in different places depending on the device you are using at the time. It's not too bad if you are able to use a cloud-based solution like Google Docs, but if you are limited to individual note taking applications on various devices things might become tricky.

Some static site generators may make things easy by having a "drafts" folder, or a status you can add into a post to mark them as draft. That's not always as obvious as it would be on a CMS and may require a lot of trial and error to get working. It also doesn't get around the "update from anywhere" benefit which is lost when using a SSG.

I'll explore ways of getting round the limitation of update from anywhere with an SSG, but be aware of this limitation when you are chosing whether this is the right route for you. You migh thave an easy way around it, or you might have to change your workflow.