It’s no secret that I’m a huge fan of Webflow.
In fact, I used the popular “no-code” tool to build and host the last iteration of this website. I also used it for some freelance projects, as well, and my clients have all only ever had positive things to say about the service.
(Heck, I even wrote a semi-viral blog post about how much I liked Webflow.)
But after two years of using Webflow for my personal portfolio website, I decided to make the switch to Hugo, a popular static-site generator (SSG) that’s powered by Google’s Go language and is often used to create blogs.
Hugo bills itself as “[t]he world’s fastest framework for building websites.” Indeed, it can generate most websites within seconds,–at less than 1 millisecond per page.
And it has been due in large part to its speed that Hugo has rapidly skyrocketed in popularity over the past few years.
And if it’s good enough for Smashing, I guess it’s good enough for me, too.
Now, while I was scouring the internet for information about Hugo, I couldn’t find very much written by people who had actually used the SSG for their own personal projects.
This was surprising, as Hugo boasts a fairly large community of users. (It’s currently the second-most-popular SSG on Jamstack.org, with nearly 50 thousand GitHub stars.)
So I wrote this blog post for those of you out there who might be in the same boat I was in–wondering if Hugo is the right fit for your next project.
Spoiler alert: It’s pretty cool.
Why Bother Switching in the First Place?
Alright, well … if Webflow is so amazing, why switch?
To be clear, I loved (and still love) Webflow for the ease with which it allows me to visually create stunning, complex, and performant websites––complete with animations, CMS compatibility, and even eCommerce.
I’ll definitely continue to use Webflow and recommend it to my fellow designers and clients. But there were a couple of factors that led me conclude that maybe it wasn’t the best solution for my new website.
First of all: I knew that I wanted to move my blog from Medium and host it on my own personal website. I’m really opposed to Medium’s strict paywall, and I’d rather use my content to drive traffic to my own website rather than to Medium.
To do this on a Webflow site would require working with Webflow CMS, which I’ve never really enjoyed.
I’ve always found Webflow’s process of working with dynamic content in general to be a bit quirky and not at all intuitive.
What’s more: to actually make use of Webflow CMS I would have had to upgrade my hosting plan to Webflow’s CMS plan, which currently costs $20 per month.
Granted, this isn’t a huge sum of money–but it’s still quite expensive for hosting, especially when there are services like GitHub Pages, Netlify, and Digital Ocean that offer free hosting for static websites.
So that was a no-brainer for me!
Second, I just wanted the freedom to play around with some of the tools and technologies I had read about but hadn’t actually been able to use on a full-scale project–tools like Tailwind CSS and GSAP, for example.
(Both of which I got to use on this website!)
So I decided to go with an SSG. But that, of course, opened up another question: Why Hugo?
I wanted a solution that would allow me to easily work with Markdown files and one that had a fairly simple template language.
This narrowed it down to Jekyll and Hugo.
And ultimately, I went with the latter because I was able to find more up-to-date learning resources online. (There are a lot of helpful guides for Jekyll, too, but unfortunately most of them are several years old.)
Making the Switch
Now the initial set-up was pretty straightforward, despite the fact that Hugo’s official documentation … leaves a bit to be desired.
I understand that it’s an open-source project, but there were quite a few basic questions that I was unable to answer.
For example: I’m still not entirely clear on the difference between Hugo’s blocks and partials––aside from the fact that blocks seem to just be really big partials.
Also, there’s nothing in the documentation about creating static pages–meaning pages that don’t make use of either the List or Single templates.
These seem like basic concepts that should have been clearly addressed in the docs.
But once I got the hang of things, the process of migrating to Hugo was fairly painless. Users familiar with popular blogging platforms like Jekyll or WordPress should find little friction in adopting Hugo for their projects.
The Go templating is easy to understand, too, even for users (like me) who had never written a single line of Go code beforehand. Depending on your willingness to learn a bit of Go templating, you can make your project as simple or as complex as you want it to be.
Hugo even comes pre-loaded with a few useful internal templates for things like setting Open Graph metadata and adding Disqus comments to your website.
Some Final Thoughts
I’ve been using Hugo for the past couple of months now, and I’ve been loving it so far.
My website is now hosted on Netlify, which is set up to trigger automatic site rebuilds whenever I make a commit to my GitHub repository. And of course, Hugo builds are lightning-fast!
So I can write my posts in VSCode, push them to GitHub–and the rest just takes care of itself.
I’m a big fan of things that make my workflow easier.
I’ll be sure to update this post if anything changes. But as of right now, I’m really enjoying the experience of working with Hugo (and Netlify). I think this is the beginning of a beautiful friendship.