October 7, 2015

“Switching Publishing Platforms”

As of the other day I have moved from Nanoc to Hugo as my publishing platform of choice. Having used a number of tools over the years I have found that static site generators are a perfect fit for me. Much in the same way I write most things using Markdown or LaTeX instead of HTML or Word, using a static site generator has helped me focus on the writing and remain reasonably platform independent.

Moving from Nanoc to Hugo took an evening of fussing with a few templates. Admittedly my site is not overwhelmingly complex but it was a reasonably easy transition. The only thing that took me a bit was learning what data was available to use and what the priority of templates is in Hugo.

Why switch?

There were a number of reasons; the primary driver was performance. On my 2011 Macbook Air Nanoc was taking 7-8 seconds to render a single page when the content changed. This was using [guard][guard] so that it would only regenerate the pages that changed. With Hugo it takes ~300 milliseconds on the same hardware to render the entire site. This was causing my Macbook Air’s fans to become pretty noisy.

Other benefits

  • Single binary - only one program to both generate and serve a local copy, no dependencies; getting up and running on a new machine is incredibly easy to do.
  • Live reloading - Nanoc has a built-in preview system but it’s horribly slow and it is recommended to use guard and an external tool to serve your static content. In addition, Hugo has built-in notifications to reload the page in the browser so can immediately see the changes.
  • Performance - Hugo is much faster than Nanoc
  • Simpler templates - Hugo’s templates follow the simplicity that I love about Django’s templates in that it prevents me from wedging a ton of Ruby code in my templates because it’s “easy”


  • No Ruby - admittedly it is nice to have the power of Ruby built into your build pipeline. You have access to lots of gems and can write code to do whatever you want. With Hugo I found that I had to write some supporting Ruby scripts to do things like generate my list of GitHub repositories by generating Hugo data files.
  • Documentation - The Hugo documentation is useful but the “getting started” path is a little more opaque than Nanoc’s. When Nanoc’s documentation failed it was reasonably straightforward to use its code as documentation

Overall impression

Overall I’m pleased with Hugo; I’ve found myself less frustrated with the process of writing while using Hugo. The performance and the instant feedback is a great improvement; I like to see what I’m writing. To anyone looking for a publishing platform that uses local files to generate a site I would strongly recommend looking at Hugo.