Static Site Generators, Part 1 - the Generators

I have spent the last few months experimenting with various static site generators and related technologies. The results have been a couple of websites like Archiphos and Minimaximum Improvision and various plans for future projects.

For those who may not know, a static site generator is a script that allows you to compile a website as static html files from content files written in Markdown and templates written in some html templating syntax. It is supposed to give you all the benefits of a dynamic site without the drawbacks. And in most cases it succeeds.

Right now there are countless static site generators (see here: StaticGen) written in almost every programming language and the majority of them do exactly the same thing. The idea has started from programming blogs and still most static site generators are blog-oriented. If all you need is a blog-like website you can choose almost any generator and it will do the work. Since most of them work using Markdown and YAML files as content it is fairly easy in most cases to transfer your content files from one generator to the other and even re-write your templates.

However, once you need something more complex, like a multilingual website, you will find that you are starting to stretch the limits of what the generator can do. There are few exceptions here: The first one is Hugo, probably the fastest and most advanced generator. It is written in Go which means that templating may be a bit weird at the beginning if you have not worked with Go templates before, but once you get it you can do almost anything with it. The second is Metalsmith, a Gulp-like generator written in Node. By itself Metalsmith is the dumbest of all generators but it is easily extensible with plugins that can turn it to a very powerful tool. There are available plugins for almost everything and, if you are any good at Node, you can write your own (most of them are small and quite simple).

It is true that there are countless personal and corporate sites made with WordPress that could have been done with a static site generator. This would make them much faster and far more secure. For the developers it will be much easier, instead of entering the Hell of WordPress templates you can keep your sanity and work with a templating system like Pug, Handlebars, Mustache or whatever you like. Hosting costs will decrease dramatically, and may even disappear (Netlify offers excellent static hosting for free). However, you will be missing one thing, the WordPress admin interface.

In most cases this is a deal-breaker in using a static site generator for anything other than a personal project. Most clients have no idea what Markdown and Yaml are and no interest in learning them. They prefer an easy to use interface close to Word or something similar. There have been some attempts to create such an interface for manipulating Yaml files with Front-Matter and Markdown but they remain quite rough and still assume, at least, knowledge of Markdown. The best solution for the moment is Netlify CMS which is far from perfect.

That brings us to what we may call, second generation static site generators. These new generators do not work (only) with Markdown and Yaml files but mostly by loading the content from a rest API that serves JSON. That means that you can have a "normal" CMS somewhere, where you write your content using a friendly interface and then, instead of writing templates for the CMS, you use that content to create a static site with a generator. The CMS remains unseen to the public and can be hosted in the minimum shared plan or even rented as a service. And the public site remains static html, easy to host, fast and secure.

There are some quite popular generators of this type like Gatsby or Nuxt and less popular but very interesting like Spike. Almost all of them are JavaScript-based, so selection comes down to weather you prefer React, Vue or working directly with Webpack.

These are really powerful tools that do bring the best of both worlds, static and dynamic. However, they are only half the story. The other half, where choices are more important and more difficult is the CMS that will serve you the JSON. More on this on the second part of the article.