Switching to Hugo and Netlify

I’ve made a few changes here, but hopefully, most of them went unnoticed. As I mentioned before, I’ve been wanting to invest more in my own site and content again. With so much I want to tackle—implementing WebMentions, syndicating book reviews to Goodreads, building a bookmarklet to make it easier for me to save links here—naturally I had to prioritize and put first things first.

So I changed the static site generator I was using as well as the hosting provider.

It’s actually not as off-track as it sounds. I had been running Jekyll for a long time now, loving the fast loading times. But there were a few issues. The most notable is my own fault: over the years, I had done a poor job of keeping things neat and tidy. The whole setup was pretty unwieldy and messy. It was to the point where I was either going to need to refactor my code anyway or switch it up altogether.

The second issue was that while the site was fast to load, it was pretty slow to generate. It was enough of an annoyance that I decided if I was going to be making changes anyway, I might as well find something fast.

I didn’t do much looking around, either. I remembered reading a post by Sara Soueidan about how she migrated from Jekyll to Hugo so I started there.

The templating syntax Hugo uses isn’t altogether that different from the liquid templating used by Jekyll. It was different enough to cause me to hit my head against the wall at first but similar enough that porting the theme over to Hugo didn’t take a lot of time.

The migration was smooth enough. The Hugo docs are a little clunky, but Sara’s post was a life-saver. If you’re moving from Jekyll to Hugo, that’s where I’d suggest you start.

I couldn’t do a better job of explaining the switch than Sara did, so I won’t even try. I will, however, highlight two things that I consider the killer features of Hugo.

The first: it is fast. Generating a new version of the site is almost instantaneous. It’s night and day from the experience of generating my Jekyll based site.

The other thing I like about Hugo is how it handles different content types. On this site, I have blog posts, saved links, talks, book reviews (now) and static pages. For each content type, I can set an archetype. The archetype is a starting point for the structured data used by each type of content.

For example, my saved links have the following data fields:

- externalURL
- date
- title
- tags

My talks have a different setup:

- startDate
- endDate
- title
- conferenceLink
- talkTitle
- location

Hugo lets you create a markdown file for each that contains YAML data structured the way that content type requires. Here’s my archetype file for my saved links:

---
date: "{{ .Date }}"
title: "{{ replace .TranslationBaseName "-" " " | title }}"
externalURL:
tags:
---

Now if I want to create a new saved link, I can run hugo new saved/my-new-link.md. Hugo will see that the content type is “saved” (defined by the directory structure here) and use the archetype I’ve defined to get the metadata in place. The date and title will be auto-populated (that’s what the funky stuff in the brackets do), and the rest will be empty and waiting for me fill in. It makes setting up different content types an absolute breeze.

Taking Netlify for a spin

Switching to Hugo let me start with a clean slate. With my now neat and tidy repo ready to roll, I decided to take the opportunity to give Netlify a try as well.

I had been hosting using Digital Ocean (who I still love and use for many other sites), but I had heard so many folks raving about Netlify’s simplicity. Also, Phil Hawksworth recently joined the team and I welcome any excuse I can get to bother Phil.

There’s not much to say about my setup there. The move to Netlify went without much of a hitch (once I set the HUGO_VERSION environmental variable). Netlify monitors my Github repo and when I push a change to the master branch, Netlify kicks off a quick deploy process. Netlify uses Let’s Encrypt, so getting HTTPS in place is a breeze.

At the moment, I’m not doing as much with Netlify as I could. It’s plumbing. Efficient, frictionless plumbing that gets the job done and then gets out of the way. That may not sound glamorous, but to me, that’s the definition of a good tool.

At some point, I plan on playing around with some of Netlify’s other features. In particular, the Lambda functions feature (in beta) could end up being pretty useful. I love static-site generators, but as Paul pointed out, they do make some functionality a bit tricky to implement. I’m thinking a few quick Lambda functions may end up coming in handy.

I don’t see myself using it, but I also like that they do A/B tests on the edge (fancy CDN talk for on a server somewhere). As a performance nut, client-side A/B tests make me weep.

The whole switch should’ve been invisible (well, it would’ve had somebody double-checked the default permalinks first). It was also very quick. Mostly that’s because I forced myself not to refactor my code too much, as much as I wanted to.

Small steps, but enough to make the process of publishing to my site a much more pleasant experience.