Jekyll was great for a while, but eventually I got tired of fighting with Ruby and gulp and other things about my setup that are probably easily fixable with moderate amounts of enthusiasm … but that enthusiasm is generally a lot easier to muster if I’m working on something new and shiny. So, onto something new and shiny.

Since I’ve been using React a lot at work, rebuilding my site with Gatsby, a static-site generator for React, seemed like a good opportunity to futz around with it a bit more.

Gatsby homepage
Gatsby homepage

Gatsby appealed to me for a couple of other reasons. First of all, my old site wasn’t handling images that well and I knew Gatsby would be a lot better at optimizing image performance out of the box and second of all, did I mention how much I hate gulp? Dustin Schau of Object Partners wrote a great post called Creating a Blog with Gatsby that I followed to get started.

Initial observations

Holy crap, Gatsby is a lot easier to get up and running than Jekyll. Granted, I already had a lot of my development environment in place thanks to my old site and a few other projects, but with Dustin’s instructions, it felt a lot less painful than the first time I had to install a non-system Ruby with rbenv and all that jazz.

The plugins are also huge. After about two paragraphs of Dustin’s post, it was pretty obvious that plugins are probably the main reason a lot of people use Gatsby in the first place, but I didn’t realize that before I started. By running yarn add gatsby-plugin-sass and adding gatsby-plugin-sass to the plugin section of my gatsby-config.js file, I was able to start using Sass immediately. That would have taken me about five extra steps and hours of fiddling with gulp when I was using Jekyll, plus it’s all automatically autoprefixed.

Lastly, Gatsby eliminates most of the need for Browsersync. Getting Browsersync working the first time drove me insane and thanks to the built-in Webpack/Gatsby magic, the site automatically reloads without additional configuration. It doesn’t come with a live link for me to view on my phone, but I don’t miss that part too much.

… Later observations

Okay, it wasn’t all roses. Using Sass was easier, but I quickly started to miss Jekyll’s Liquid templating language. Instead of being able to add a quick {% if page.previous.url %} or {% if %} for next and previous post buttons, I had to mess with the exports.createPages API to add context, which I then passed into my blog-post.js template. Let’s just say: I have a lot more to learn about GraphQL.

It was also weirdly a lot more effort than I was expecting to get all the head tags working, particularly for open graph. The post recommends using React Helmet, a “document head manager for React” to … manage the document head. Created by the NFL, it’s a lot more robust than what I needed for my little blog and it was a bit tedious to write all the conditionals to cover each use case. Similarly, setting a favicon also required a specific plugin which seemed a bit overkill but it was simple enough to install so 🤷‍♀️.

While it definitely took longer to get some of my old site’s functionality working in Gatsby, the time I spent learning how to do them felt more worthwhile and broadly applicable than diving deeper into Jekyll so I didn’t mind.


I finally have RSS on my site! (That makes this a #realblog now, right?) The Gatsby Plugin page lists a handy dandy feed plugin and with a bit of tinkering, I had it working nicely. The documentation gives a default example, but it only works if the original query includes the slug field for each node. My query, which I’d written from the tutorial example, did not, so I customized the plugin options to use the node.path.frontmatter data instead.

Other plugins

As Dustin’s post promised, the plugin options really seem to be where Gatsby shines. A few other useful ones I found were:

  • Smartypants, for replacing dumb quotes with “smart” quotes.

  • Offline, for making the site work offline or with a poor connection.

  • Google Analytics, for quickly adding GA’s tracking ID.

  • PrismJS, for custom syntax highlighting in markdown code blocks.

  • Netlify, for optimizing the site to work with Netlify.

Clean up

All in all, moving from Jekyll to Gatsby was a good weekend-sized project and a nice introduction to GraphQL. I really appreciate having less to configure in the build process, even if it cost me some simplicity elsewhere. There are a few more components I should refactor to really get the benefit of using React, but that’s a job for another day.