Sometimes Software Is Done, or Why Hugo Why (2024)
Posted4 months agoActive4 months ago
commaok.xyzTechstory
heatednegative
Debate
80/100
Static Site GeneratorsHugoSoftware Maintenance
Key topics
Static Site Generators
Hugo
Software Maintenance
The author discusses their frustration with Hugo's frequent breaking changes and feature churn, sparking a debate about the trade-offs of using a static site generator and the importance of stability versus new features.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
41m
Peak period
44
0-3h
Avg / period
9.5
Comment distribution76 data points
Loading chart...
Based on 76 loaded comments
Key moments
- 01Story posted
Aug 31, 2025 at 5:11 AM EDT
4 months ago
Step 01 - 02First comment
Aug 31, 2025 at 5:52 AM EDT
41m after posting
Step 02 - 03Peak activity
44 comments in 0-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 1, 2025 at 3:59 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45081703Type: storyLast synced: 11/20/2025, 3:01:49 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://github.com/jmooring/hvm
Helpful for switching between different versions of Hugo.
With Wordpress, you have to worry about PHP, a database, etc. It’s the difference between being able to use GitHub pages, and needing either a VPS or shared hosting
As long as you have access to a computer that can run Hugo Version Manager (and who knows what else).
I am being facetious, obviously.
(And in particular, every design failure related to backwards compatibility can be solved with a virtual environment, evidently)
This, but for all software ever. In the nightmare realm we've apparently decided to settle down in we forgot the one way to make actually secure software: Run the complicated parts somewhere offline.
A security vulnerability is much less scary if the computer can't communicate with anything. It's the only way for us to get out of the pit of infinite work we've dug.
I will be trying Astro for the next site.
It's been over 18 months. Has the author switched?
The current Hugo version is 0.149.
So it looks like the author has indeed gone according to his short terms plan:
> And in the meantime, I’ll just compile Hugo myself from source, never update it, and live in the ever receding past.
Does anyone have a better go to?
I've been using Zola now for years, and I'm really happy with it. Good features, and nice and stable.
https://quarto.org/docs/websites/website-blog.html
What does Hugo et. al. add on top of that?
I posted this last year: https://github.com/gohugoio/hugo/issues/12693#issuecomment-2...
It makes troubleshooting really tedious.
As for updating versions safely, I highly encourage anyone to write a little tooling to build your site with version A and version B into different directories and then diff them to make sure nothing unexpected changed.
That is something I documented in a very long post where I went over converting my 500+ post Jekyll site to Hugo at https://nickjanetakis.com/blog/converting-my-500-page-blog-f.... If you search the page for "Updating Hugo Versions" you'll find the section.
If so, huge thanks!
It was a massive pain the rear, and I'm so glad it's behind me. Never again, unless I'm getting paid for it!
I have worked with WordPress in the past but not for my site.
yea I agree with OP, some software are better done.
> Build failures of my static site, which has maybe a few dozen posts...
> Suggestions for alternatives welcome...
Plain HTML? No build process needed.
But one will need to convince me that it's less annoying than having to use some sort of blog engine, static or otherwise.
You can write scripts to automate some stuff, but you are just easing into using a custom blog engine if you do this.
However, rolling your own SSG should take a few hours. You can look at features and CHANGELOGs of others, and decide if any of those sound neat to implement in your SSG, but to be honest, you can probably build something with a markdown converter or a liquid template library and `make` in about as much time as many SSGs require you to configure.
Want a specific theme from a well known SSG? If the license allows, port it.
I've been using hugo for a while and I'm running into similar issues. Considered jekyll and many others, but I've kind of resigned myself to spending a couple of evenings this week just writing my own very basic tool, probably based on a Makefile and some standard command line tools, and maybe a small amount of custom code that won't change under me (it'll be in my private repos).
- RSS/Atom
- the post list
- next / previous links
by hand (and remember to fix the link tests if you change some post title)
And if you want to change the page structure layout a bit, you'll have to update all the posts by hand as well.
You could do without all this but that means it's difficult for readers to follow what's your writing.
I didn't had the same issues as OP, but Hugo docs are so confusing that I just gave up and switched back. Jekyll works OK for my simple needs, and still does.
For those interested, there was also a partial-Jekyll-Golang-port, https://github.com/osteele/gojekyll
I have something to say, I just go to https://www.dreamwidth.org/entry/new and write, hit "Post" and I'm done. No need to worry about whether the software is up to date, deal with security issues, etc. That's all someone else's problem.
If it can provide the whole stack itself, so that I don't have to know anything at all about the underlying technology, then sure!
This was the reason why I invested in my hacky blog build and deployment script instead of moving my stuff over to Medium or Netlify when that was popular. You gotta look out for yourself.
People are trying to “keep it simple” by introducing a dependency for everything. They say: “There is already an off-the-shelf solution, so why code it yourself? Just pull yet another dependency and be done with it.”.
The problem is that this is never actually the case. In reality, the dependency does 80–90% of what you want, plus 27 other things you don’t need or want.
Then you spend time understanding the dependency, configuring it, coming up with and maintaining workarounds for the 10–20% that you need but are not solved by the tool. Then you need to update and maintain the tool and its configuration, and you won’t ever actually “be done with it”.
My suggestion: Don’t introduce a huge and complex dependency for a static blog with a few dozen posts. When what you want is just compiling a few templates, just do that: Choose a templating language, create a few templates, write a Makefile (or Meson build script, or whatever else), and actually KISS.
https://www.npmjs.com/package/is-even
Also, check the dependencies :)
Some of those 27 things introduce security vulnerabilities, so you better study them thoroughly even if you never intend to actually use them.
For example, all those deserialization libraries, where the intended usage is "load values from a string, and set them as properties to this object", but some very clever person decided to add extra functionality where if you use some special syntax, the library will load contents of a file on disk, call an internet end point, or instantiate a specified class. All these extra features are enabled by default.
So you are like "send me an XML/JSON/properties file containing a few strings and numbers, now I can easily parse them" and the attacker is like "okay, here is an XML/JSON/properties file instructing your computer to read these files from your disk, send them over the internet, and for extra fun create instances of these security classes and tell them to do some weird stuff" and the library is happy to comply.
If the authors at least made these cool extensions opt-in, but I guess someone careful enough to think about that would already be careful enough not to add the feature in the first place. (But what if some people want the extra feature? Then make the library so that it supports plugins, and publish the feature as a separate library which will be used by those who want to use it.)
They keep using the version 0.x.y, which means, they can at any time break things and don't care about backwards compatibility.
I use versioned instances of Hugo and had in all these years zero issues. I can simply test the new version, then do the required changes and adopt it for my build.
Even better, it's a standalone binary....
...because I'm still on version 0.18.1, and it was easier to just keep a copy of the binary in ~/bin than deal with all the breaking changes :-D
I run a dumb old version of Hugo for my two blogs and resume which are deployed with a custom build system I built in a rush. They haven't exploded yet!
Are you supposed to update these things?
In the end I sat down two weeks and wrote my own generator in python for my blog. Even wrote my own markdown parser for it. It's a sub optimal implementation for sure, but at least it's all my faults and I may fix them.
As a number of others have mentioned - pin the version of Hugo you use for a particular project. I do this and it works great for stability. Then I upgrade when I have the time or the need or I want to standardize across projects.
It's more upfront work of course, but you don't have to be bothered with the tool changing underneath you.
Its been a great experience and completely solid to use. Need a URL shortener feature? Code it into the generator. Want some static search? Code it into the generator. Want to generate a newsletter for certain posts? Wire your generator up to SES and do it.