I’ve been a web developer for over a decade now, and have in that time
experienced my fair share of CMS woes. I’ve gone through the stages of using, extending, creating and ultimately dismissing it all. You name a CMS and I will most likely have played with it to some extent; not because I love CMSes (the contrary), but because of my insatiable desire for a CMS that just WORKS.
After years of searching, using, extending and creating I ultimately quite literally dismissed it all in favour of what is essentially plain HTML. Like many I started playing with static sites generators, at first not quite “getting it”, then having my “Aha!” moment. Eventually I wanted to use it for just about everything. I went from years of developing and extending advanced and overly involved CMSes to plainly just “using my content”.

Using Your Content

This is the main difference I see between using a CMS and a static site generator; you are controlling your content, rather than controlling a system which then controls your content. When you write a blog post for a static site generator you have full control (the link, not the over how you want that blog post to appear. You want to write it in markdown, include a bit of custom javascript and have your own sidebar? It’s a bit unusual, but sure – have at it! It’s a breeze with a static site generator because you don’t have to teach some over-arching system how to make sense of what you’re doing. You control your content through your content, rather than controlling your content through a system which is biased in many ways and leaves you struggling to implement things the way you envisioned them.

So What Is a Static Site Generator?

A static site generator is exactly what it’s name implies; it is a “generator” which pieces your site together, based on your instructions. Like a CMS it is just a concept, there are many implementations. This website for example is generated by DocPad, but there are many alternatives.
Essentially you create your site by writing your articles in (for example) markdown, and providing some meta data with your article, eg. the date, title and the “layout” that it should use. The layout can be a simple HTML file which includes your JavaScript, CSS and a reference to where your article should be, not unlike the way you would have a template in a CMS. The difference here is that it’s all handled from your filesystem and with your actual content (the article) as the main driver of how everything ought to be generated.

Not For Everyone

Now I can already see many people reading this thinking “but what about the clients?” or similar thoughts. The simple fact is that static site generators are not for everyone, and will never replace the huge selection of CMSes available. It is simply a new alternative with a limited applicability. For example static site generators in their current state are mostly unable to cope with large databases of data. They are able to handle it, but the time to generate your site will grow linearly with the size of your database.

Current Limitations

So it’s likely not a good idea to use a static site generator for a huge site without having a strong gameplan for handling the issues you will be facing down the road. You’ll also want to be cautious about using a static site generator for websites containing a lot of dynamic (user generated) or session specific data, because your website is generated only once and needs to be suitable to all visitors at any given time of the day. You could work around this by “filling in the blanks” with AJAXed data, but search bots will not pick up on this data and so your SEO will be negatively affected.
Another issue I found is developing using a static site generator can severely reduce your productivity, because something as simple as modifying a CSS rule or changing an attribute in your layout file will cause your site to regenerate and so you cannot instantly review your changes.

The Solution

Most of these limitations seem to boil down to the same issue; regeneration is costly. This isn’t an issue for most CMSes, since pages are generated in real-time (when you visit a page on a website, it is generated at that time for your specific visit). Can’t we meet somewhere in the middle though? Actually, we can! The way I see it, most static site generators are essentially a very strong caching system. There is no reason we can’t invalidate our content at runtime and have it regenerate for one reason or another – but we don’t want our entire site to regenerate every time!
So what if we borrow a little bit from the CMS systems; we preserve the static site generator functionality while adding a small dynamic piece in between which simply checks whether our content is still up-to-date or whether it needs to be regenerated. We then either pass off the request to the up-to-date static file or re-generates the file on the fly.
But – how can we regenerate a file on the fly if the entire site is being regenerated and we therefore have to wait for this entire process to finish? Well why does the entire site need to be regenerated? Because files are inter-connected, that’s why! Do’h. But hold on, can’t we intelligently decide “which” files are connected, and prioritize the generation of the file that we actually need, whilst letting the rest of the files regenerate in the background without bothering the end-user? We totally can! And this is what I would like to see happen in the future, and is something that has already been recognized (to an extent) in DocPad and likely in other static site generators as well.

The Future

So for me, the future is very bright. I don’t anticipate that I won’t ever touch a CMS again; as I said static site generators do not replace them, they merely offer an alternative approach which will be relevant in some cases, and not in others. And I look forward to seeing their relevancy increase.
Title image courtesy of José Alejandro Cuffia on Unsplash.