Choosing A Static Site Generator

Actually, you don't really have to. Choose a site generator, that is. You can just write plain HTML yourself and push that to your GitHub User Pages. Now, writing plain HTML distracts from writing content. Quite a bit actually and that's where the generator comes in handy. You write content in a much simpler markup language and have the generator convert that to HTML for you. Commit the HTML, push, et voilà, your site is up.

So, of the four I mentioned before, which one made my cut, and why? JekyllBootstrap and ruhoh didn't make the cut because they are not packaged yet(?) for Debian testing/unstable. I have been using that for my day-to-day computing since ages, both at home and the office. Having the Debian maintainers look after my needs cuts the amount of work that I have to do.

That leaves us with Jekyll and Pelican. A Jekyll based site has the advantage that you can simply keep that in your master branch and push. GitHub will take care of the conversion for you. Less work for me, right? Yes, but at the cost of no longer being in control of my own site. The GitHub conversion process is not Just Jekyll. It has a few GitHub specific tweaks thrown in which may result in a different site than you had in mind. These tweaks may change at GitHub's whim and if you want to keep up with them, well, you're in the same boat as with JekyllBootstrap and ruhoh. You will have to do the legwork yourself.

So, let's cut out the GitHub middleman and use Jekyll to convert to HTML ourselves, you say. Good thinking! Perfectly good approach. But when you go down that path any static generator will do. That makes Pelican just as good an alternative as Jekyll. Then which one shall it be? Jekyll or Pelican? Both come with a pile of plugins and heaps of themes. Why prefer one over the other? In the end, it is really a matter of personal preference.

I went with Pelican because it's implemented in Python, a language I've been meaning to learn. Jekyll is written in Ruby, in case you are wondering.