Like most people I know in tech, I’ve accumulated a number of domains over the years. Domains that have been lying around gathering dust. Yesterday, as I sat on the couch recovering from a back/hip injury, I had a minor epiphany. Or a reaction to muscle relaxers. Either way, there was just enough time left in this year to turn one grand unfulfilled intention into gratuitous but fulfilled reality. This blog.

For a first entry I thought I’d share some of the decisions and steps I went through to get from fever dream to reality in just a couple of hours. If you’re more interested in the how than the why, jump to part 2.

Picking an approach

Get something going with minimal effort and expense

Launching Rhythm doesn’t leave me much time. Kelli is a certified wizard on Squarespace and we’ve used them in the past with great success. But with the explosion of static site generators and web application frameworks in recent years, this seemed like a great excuse to take one for a test drive.

First decision: I thought I could deliver something almost as easily but significantly cheaper without a CMS.

Spend time generating content instead of code

I really didn’t need any advanced features and I have plenty of other places to spend precious coding time. I am curious to play with Nuxt.js or Next.js, but I wanted a solution that required minimal - or even better, zero - coding.

Second decision: I thought a static site generator would be easier to get going and provide a simpler content development experience.

Picking a static site generator

So you’ve decided a SSG fits your objectives better than a framework. Think you’re ready to build? Ha! staticgen.com offers a curated list of 400 to choose from! Welcome to the jungle.

For the last two years the majority of my development has been in Node.js, so I started by looking at some options in the JavaScript family: Gatsby, Hexo, and 11ty. Ultimately I think any of these could have worked. And as much as I liked what I saw (especially the opossum floating on the red balloon - thanks 11ty!), I still had some reservations.

I’d consider myself no more than a tourist in the lands of Ruby or Go, but I decided to look at Jekyll and Hugo anyway. I know they’re both hugely popular, but if I’m honest I didn’t really expect to pick either.

Yeah, I decided to go with Hugo.

Ultimately my decision came down to three things that I felt were more important than extensive experience with the language used to build the SSG.

1. Build times The more I dug, the more I became concerned about build time. I know I’m going to struggle to find time to dedicate to blogging and to stay focused. I did not want any precious cycle time spent waiting on builds. I’m also planning to set up a CI/CD pipeline so build time will have a direct impact on my monthly bill. Long build times seem to be an issue with many if not most SSG’s. Gatsby seems to recognize this and has worked to try to bring build times down - but still Hugo is on a different level. When comparisons of build times are this drastic, you have to pay attention.

2. Did I mention I don’t want to do a ton of programming on this project? Pretty much all the SSGs I looked at support a plug-in architecture of some kind. What I liked about Hugo was how users seemed to need it far less often. For my blog’s simple aspirations, I likely wouldn’t need plug-ins for Hugo at all. When you look at the GitHub issues for all of these projects, I think you can see the benefits of extending your SSG as little as possible.

The fact that Hugo seems to favor built-in capabilities over extensions also made me far less concerned about not having deep experience with the underlying language.

1. Available Themes This is clearly based on personal taste, but I preferred the themes I demoed for Gatsby and Hugo over Jekyll, Hexo or 11ty.

Factors that might have changed my decision

I think it’s important to re-state that any of the SSGs or platforms I considered could have worked. I felt like Hugo fit best for my specific needs for this project. But here are some of the factors that might make another SSG the best fit for your project:

• Need for more complex functionality

I’m only planning on basic searching / commenting

• Need to pull data from multiple sources

I’m only planning to write posts in markdown - simple and portable if I want to switch later

• Lots of rich media content

I’m only planning on simple mastheads, graphs, and screenshots. Nothing that makes me worried about performance, especially when served using CloudFront

Honestly, if these were the primary concerns for me, it would have been hard for me to go with anything other than Gatsby. It’s highly-extensible, seems to have decent build times, and has advanced support for data sources and rich media.

To Be Continued…

In part 2 I’ll detail how I got Hugo going and launched this site using AWS Amplify.

Photo by Daniel McCullough on Unsplash