Migrated From Jekyll To Hugo
A few weeks ago, after experiencing slow compile times with Jekyll and being frustrated with my publishing workflow, I decided to explore other static website generators. That exploration led me to Hugo, which is a little different than most other static site generators in that it is a native application with no dependencies (Hugo is built with Go; Jekyll is a Ruby app).
I ended up porting my entire website to Hugo and I now have an awesome publishing workflow. But before I get into that, let me delve a little deeper into the problems I was having with Jekyll that led me here.
Slow Compile Times
My website isn’t huge, but there’s a non-trivial amount of posts here since I restored my archives a few months ago. After I did that, whenever I had Jekyll running, it took significantly longer to compile (which was expected). Then, I added some logic to my theme’s sidebar to display the archives in a very specific way, and compile times became abysmal.
I know my little archives snippet was to blame, but I don’t think it was so complex that it should have warranted that much of a slowdown. I also plan on adding more to this site over time, so this problem would only get worse.
Bad Publishing Workflow
The worst part about my whole setup, however, was my publishing workflow, ever since I moved away from GitHub Pages and their stellar Jekyll integration. It’s partially my own fault in my choice to use a shared web host (HostGator), but I’m pretty happy with them otherwise and I wasn’t ready to switch to something else just yet.
So when I went to update my website, the most obvious way was to upload the built website via FTP. Unfortunately, this took forever because of the amount of content on my website.
Then, I discovered the “synchronize folder” functionality in Transmit and I thought that would be the answer (it’s supposed to only upload changed files). Nope. When Jekyll rebuilds a website, it touches all the files in such a way that Transmit can’t detect which files haven’t been changed and it just ends up re-uploading most (if not all) of the website anyway.
At this point I was a little frustrated because things were so much simpler back when I was on GitHub Pages (which was free), and now I’m having to re-upload the entire website whenever I write a new post or a make a simple theme change.
After some digging, I discovered HostGator provides SSH access to my shared server. I thought that if Ruby is installed, I could just install Jekyll and compile my website straight on the server—no uploading necessary.
Nope. The installed Ruby version was extremely old and incompatible with Jekyll, and there’s no way to upgrade it. So much for that idea. It was at this point that my search for a new static website generator began.
Deciding on Hugo
Hugo caught my eye because it has a focus on speed, which was my first issue with Jekyll, and it’s also a native binary with no dependencies—which should solve my second problem. I took a look around at the docs and liked what I saw, so I decided I would upload the small Hugo binary to the “bin” directory of my web host and run it from an SSH session.
After uploading, I logged in via SSH and ran:
$ hugo version
It worked! This was it. Next thing on my todo list was to port my website over to Hugo.
This was really time consuming, because along with the migration, of course I wanted to totally redesign my blog from scratch. I had been working on a new responsive website layout for a separate project recently, which I was very happy with, so I decided to use it as the basis for my new Hugo theme.
Creating a Hugo theme was tougher than I thought it would be, mostly because I assumed it would be as easy as creating a Jekyll theme. The process is very similar, but Hugo uses Go templates, which are less intuitive and seemingly less flexible than the Liquid templates that Jekyll uses. I also didn’t discover there were other templating options for Hugo until I had already made a lot of progress, so I didn’t want to switch to something else that wasn’t even guaranteed to be any better. All in all it wasn’t too bad, just a little more challenging than I expected.
It took about a week and a half of nights and weekends to finally get the theme finished, and an extra night to port over all my posts. That part was pretty straight-forward, with the majority of the work being a front-matter string change from
layout: post to
type: post for each entry. However, what took the most time, besides coding the theme, was finalizing the new design. I also wanted a totally separate design for my resumé this time (to make it more resumé-like). It was a lot of work, but all in all, I’m very pleased with the result.
And the best part: my website compiles instantly. Hugo is as fast as they say. So that takes care of the first problem I had with Jekyll. But that wasn’t the end of my problems.
More Publishing Issues
So how did my planned SSH-based publishing workflow turn out? Not good. When I was finally finished with everything, I uploaded the entire project to my web server and then logged in through SSH.
When I ran the
hugo command to build the website, it was a total fail. Hugo crashed, complaining about the number of processes or something like that. Anyway, it was a total blocker since I can’t control any of the settings on my shared web host and nobody else on the internet seems to have run into this with Hugo so I was completely out of luck.
In hindsight, I really should have done more than just run the
version command to see if Hugo would work on my shared web host. I have to admit though, part of me was excited about the challenge of porting everything over to Hugo, so I did get some enjoyment out of it. I also got a really solid new website design out of the whole thing, so that’s a plus.
At least Hugo seemed to be more efficient than Jekyll as far as touching files when it does a compile, so I had a little better luck using “synchronize folder” in Transmit, but this was still a less-than-ideal workflow (and even so, was more hassle than I wanted).
Overall this whole aspect was a bit of a bummer, especially considering that I went through all the work of porting my site to Hugo mostly to get around this issue. I probably wouldn’t have went forward had
hugo version failed in my initial test. Note to self: do more (and better) testing next time!
Git to the Rescue
After the first time I uploaded the completed Hugo website to my server, replacing my existing Jekyll blog, I had an epiphany:
What if my “public_html” folder was a Git repo? Then if I have Hugo output to a local repo, I could just check my changes in the same way I used to when I was on GitHub Pages!
After a quick test, I verified that Git was indeed installed on my shared host, but a really old version (come on, HostGator!). Thankfully that didn’t seem to matter.
It didn’t take long to find a great guide on setting up a Git repo on HostGator. I followed it, minus the SSH setup stuff that I already did, and lo and behold: everything finally worked perfectly.
I am now able to build my website locally, and check in the changes using Git. This is exactly what I was wanting from the beginning. My perseverance paid off. But the really crappy, ironic thing is, I could have done this with my old Jekyll setup (*face palm*). There’s nothing about this Git workflow that is Hugo-specific.
Oh well. So far I’m really happy with Hugo, and I think its extreme speed will really pay off in the long run, especially as my website grows. I also like how there’s no dependencies (I’ve run into Ruby version problems with Jekyll in the past), so this setup is very reproducible. I also learned some new things (Go templates, Hugo, Git on a shared server, etc), so there’s that.
Here’s hoping that I stick with this design for a while.