How I migrated this blog from Jekyll to Hugo
Olav Ringdal
First of all: yes, I know. The last post on this blog — fine, the only post on this blog — was about migrating from WordPress to Jekyll, and it ended with me promising to write more now that the friction was gone. That was two years ago. In my defense, I have been busy. Partly with work, and partly, as you are about to read, with the blog itself.
Here is what happened. Last month I got a new laptop, cloned my Jekyll blog, and typed jekyll build. What followed was ninety minutes of my life I will never get back: the wrong Ruby version, then rbenv, then bundle install, then nokogiri failing to compile its native extensions with four hundred lines of C compiler output, then a libxml2 flag I found in a GitHub comment from a man who I hope is doing well. All of this so that a program could convert Markdown into HTML.
The blog itself was fine. The blog was twelve files. The toolchain required a version manager, a dependency manager, a C compiler, and a sacrifice.
Enter Hugo
Hugo is a static site generator written in Go. The installation procedure is: you download Hugo. That’s the whole procedure. It is a single binary with no runtime, no gems, no Gemfile.lock merge conflicts. It does not care which Ruby I have installed, because — and I cannot stress this enough — it does not involve Ruby.
And it is fast. Numbers, because I measured (of course I measured):
Jekyll $ time jekyll build → 28.4s
Hugo $ time hugo → 0.4s
Seventy times faster. For one post, admittedly. But think of the headroom.
The migration itself took an afternoon:
- Front matter is the same YAML, so the post moved over untouched.
- Permalinks stay
/:year/:month/:title/— same shape they’ve had since the WordPress days. Cool URIs don’t change; my migrations are invisible at the URL level, which is the only level anyone respects. - I’m using the Ananke theme, deployed with a little Wercker pipeline that pushes to the server on every commit. The future is now.
- Syntax highlighting, RSS, the works — all built in.
Why this matters
The point of a blog like this is to own your content: plain text files, in git, rendered by a tool I can hold in one hand. Every minute not spent fighting the toolchain is a minute available for writing, and I intend to use those minutes. I have a drafts folder now. There are four drafts in it. One of them is about Go’s error handling and I think it’s going to be good.
So: new engine, same blog. Expect the writing to pick up — for real this time. The friction is finally gone.
— Olav