A long time ago, I decided to try out Jekyll for my website. However, it all felt too convoluted: the ruby gems I needed to install, the configuration options for the site, the theming. I was given a template that already made several design decisions for me, and I didn’t like it. So I wrote my own back end and front end, and was happy with it for a few years, periodically updating the look of the site. I even made a post on the site, called “Ditching Jekyll”, with the glorious contents:

This morning, my guilt finally took over and I ditched the idea of using Jekyll. For the better, probably. I sat down to code, and got up several hours later, victorious! Thanks to a handy tutorial on Python and Flask written by Miguel Grinberg, found here [“here” is not a link], I wrote a bare bones website to host my silly blog posts and projects.

Recently, however, I started to do a little more writing for the blog. My posts grew fairly long, and started to include nontrivial pieces of code, ones that I couldn’t write and be sure without checking that they worked. Additionally, I felt an increasing need for version control. This was all very difficult through a custom backend, which doesn’t come for free with features such as tracking changes and including code snippets. My workflow boiled town to the following:

  1. Write the skeleton post in a local Markdown file
  2. Write the relevant source code in a proper source file
  3. Copy-paste the new source code into the Markdown post.
  4. Copy-paste the full post into my custom website’s input box.

There are two steps where parts of a writing project can become out of sync with each other! Changing the source code means that you eventually have to update the Markdown file with the changes, and modifying the Markdown file also means that eventually, you’ll have upload the new file to the website. It’s inefficient, and there’s a lot of redundancy.

With this in mind, I think there are many advantages for using a static site generator for a personal website / blog. They are as follows:

  1. Content is first class. Your posts are files you can edit in any way you like, rather than opaque entities stored in a database. This also has the added benefit of allowing you to properly use version control with your posts.
  2. A static site generator can support complex multi-file setups. It took me about half an hour to configure my posts to pull code snippets from other files on disk, thus freeing me from having to copy-paste source into my posts.
  3. A custom back end is overcomplicating things. You write your own code to render posts, your own code to log the user in. This way you’re not only spending more time than you need, but you’re also adding more surface area for possible errors and bugs.
  4. A static site generator allows for the re-use of ideas and code. Rather than reinventing your own solution for tagging, rendering Markdown, syntax highlighting, and the like, you get these solutions out of the box, with a body of online questions and answers that have been generated over these very subjects.

Having come to this conclusion, I will be switching my website to Hugo, which seems to be easier to configure and customize, without making too many assumptions about what you want in your website.