Moving to Hugo

It’s been longer than usual since I made a redesign of the web site. Jekyll had been serving my purposes well, but I managed to concoct two excuses for changing. I’ve been slightly uncomfortable with handling the various dependencies with respect to other Ruby gems. Unsurprisingly, as the site got bigger and bigger, the time that Jekyll took to build the site has gotten longer and longer. The real reason for the redesign, though, is that I just like the chance to learn and work with something new.

I thought about Pelican, which is similar to Jekyll, but written in Python. I’m more comfortable hacking around in Python than I am in Ruby, but that was the only advantage I could see with Pelican. Hugo has been getting a lot of press lately, and everyone remarked about it’s apparently amazing build speed. It also installs as a single binary, so there is no need to manage dependencies.

Building the Hugo site was relatively simple, and anyone with some experience with any static site generator should have no problem. Hugo has a command to import a Jekyll blog, which worked very well. I had to clean up some meta-data, but after a bit of search and replace magic with regular expressions on the post directory, everything worked.¹

I thought about designing my own theme, but quickly discovered that it would take more time than I need to be spending now, so found this excellent academic oriented theme by George Cushen, cleverly called “Academic.”

The Internet chatter was correct — the site builds very quickly.² I saw soon face, though, with the one disadvantage of Hugo compared to Jekyll, at least for me. As a professor at a small liberal arts college with a primary revenue stream of tuition, I prefer to use free services when possible. Github hosting was ideal. Since a large portion was powered by Jekyll, I could just push the source to Github. Github would build and serve the site automatically. It met two important criteria, simple and free. I was especially happy with that after discovering how to easily post from iOS.

Now, I had to build the Hugo site, then push the source to one repository and the HTML to another. It wasn’t difficult, but it didn’t have the single-step ease that I wanted. I stumbled on Forestry, which is a CMS for Jekyll and Hugo sites. It works amazingly well, and could be a great tool for people who want the benefits of static sites but don’t want to mess with the command line. It can be configured to build and push to the deployment repository when a change is made to the source repository. For me at least, it didn’t work well in conjunction with the command line, though. When it rebuilt the site, it changed a number of source files, and I would forget to pull those changes before working on something. I was soon tired of cleaning up merge conflicts.

Many people use either Travis CI or Wercker for deploying static sites. Both are tools for building and deploying software, but will also build and deploy static sites. Unfortunately, I just couldn’t manage to make either one work. Finally, I stumbled on Netlify. Netlify is a bit different from the others in that it builds and hosts, and, for the service that I need, all for free. It was easy to configure, the build worked perfectly, and I just had to point the domain to Netlify instead of Github. I write using Emacs or Editorial, push the post to Github, Netlify detects the change, then builds and serves the site. For anyone who is interested, the source code for the site is on Github.