Hugo

I ran this blog on Hugo for over a year before moving it to Astro, so none of what follows is theory. I built with it, broke it, deployed it, and I’d still recommend it. Depends on what you’re building, though.

Why (and When) to Use Hugo

I came to Hugo after years of WordPress, and it fixed basically everything that made me leave: no plugins nagging about Pro versions, no database to back up, no admin panel to secure, no mystery JavaScript on every page. I wrote the full rant in Why I Switched from WordPress to Hugo, including the emoji script that still haunts me.

Hugo is the right call when your site is content. Blogs, documentation, landing pages, portfolios. If “Markdown in, HTML out” describes your entire requirement, Hugo does exactly that and gets out of your way.

The performance story sells itself. This site scored 100/100 on Lighthouse across the board while I barely tried, because static HTML has nothing to be slow. No render-blocking plugin CSS, no jQuery from 2014. Nothing.

Themes and Templating

Here’s where the honeymoon ends for most people. Hugo templates are Go templates, and Go templates are cursed. I said that when I switched to Hugo and I stand by it. {{ range where .Pages "Type" "posts" }} is not something a normal person writes on the first try.

The theme ecosystem softens this. There are hundreds of free themes, and if one fits, you might never touch a template at all. But the moment you want to change how a theme works, not just its colors, you’re learning Go templates. Budget a weekend and lower your expectations.

My advice: pick a theme close to what you want and keep your overrides small. A layouts/ folder in your site root beats forking the whole theme.

Organizing Content

Hugo’s content model is genuinely good. Your posts are files in a content/ folder, front matter on top (TOML or YAML), body below. Page bundles let you keep a post’s images in the same folder as the post itself, which sounds minor until you’ve maintained a blog where images live in a completely different tree.

Taxonomies come for free. Tags, categories, whatever you define, and Hugo generates the listing pages automatically. Archetypes give you templates for new content, so hugo new posts/my-post.md starts with your frontmatter skeleton instead of an empty file.

Deploying a Hugo Site

The output is a folder of static files. That’s the whole deployment story, and it’s the best part: any web server, any static host, any CDN works. No Node process to keep alive, no platform lock-in.

Mine ran as an nginx container behind Traefik, with the built site mounted in. Build, copy, done. And since builds take a second, CI is trivial. There’s no “the deploy takes 20 minutes” with Hugo. Ever.

Hugo’s Limits

Hugo is radically static, and that cuts both ways. The moment you want anything dynamic, a contact form, a view counter, comments, you’re duct-taping external services onto it. Each one works. None of them feel great.

That’s ultimately why this blog now runs on Astro. Not because Hugo failed, but because my requirements outgrew “purely static”. The whole story is in Why I Switched from Hugo to Astro, and it starts with a love letter to Hugo, not a takedown.

So: content site, no dynamic features, maybe some templating tolerance? Hugo. Still one of the best tools I’ve used.