> Hugo is officially on the chopping block. Suggestions for alternatives welcome.
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.
Viliam1234 · 1d ago
> In reality, the dependency does 80–90% of what you want, plus 27 other things you don’t need or want.
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.)
nunez · 1d ago
I'd actually recommend Casey/just over a Makefile for this. I love me some Make, but Just is so much nicer.
Wow, I think maybe the author was joking, or pulling a prank on vibe coders. Bc AI will definitely pull that.
ajsnigrutin · 1d ago
It's a very old package :)
Also, check the dependencies :)
figassis · 10h ago
Dear Lord in Heaven. is-odd -> is-number?
ApeWithCompiler · 1d ago
I had a similar experience with Hugo and the PaperMod theme. Such a large tool with all the dependencies to then just fail because of version mismatches with the theme.
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.
madduci · 1d ago
If you rely on Hugo, then why don't you use a versioned instance of it? You should.not always run the latest version, if you don't want to.change things that are broken.
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.
gedy · 1d ago
I've always been surprised at people who don't version dependencies, even though package managers like npm support this easily. Then they complain of "DEPENDENCY HELL omg" when they've got "*" as a version, or try and bump something critical 3 major versions in the middle of other work. Like why
tga · 1d ago
The alternative I'd suggest to someone using Hugo for a simple site/blog would be https://www.getzola.org. Single binary, batteries included.
Does anyone have a better go to?
bovermyer · 1d ago
I switched from Hugo to Zola for a reason similar to the author's.
I've been using Zola now for years, and I'm really happy with it. Good features, and nice and stable.
samwho · 1d ago
This is what I use and I’ve been very happy with it for many years. It hasn’t caused me any trouble and as far as I can tell it hasn’t changed in the whole time I’ve used it.
NeutralForest · 1d ago
I've used Zola and it gets the job done in a few commands, nothing else I need from it tbh.
asimpletune · 1d ago
I’ve used Zola for years and I love it. Good maintainer, does what it needs to, and it’s
fast.
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.
privatelypublic · 1d ago
Did you also do wordpress to jekyll and/or hugo?
If so, huge thanks!
nunez · 1d ago
Not OP. I did, though I don't think I wrote how. I had to convert everything to Markdown, fix a whole slew of Wordpress-isms in the Markdown it produced and convert Wordpress image references to inline functions. I ended up writing my own partial for handling images, though I don't remember why I did this anymore.
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!
nickjj · 1d ago
Nope, I started with Jekyll sorry.
I have worked with WordPress in the past but not for my site.
Milpotel · 1d ago
That's exactly my experience with Hugo and why I stopped using it.
akshitgaur2005 · 1d ago
What do you use now?
hn_throw2025 · 1d ago
I found embedding some React into a Hugo site involved a few workarounds…
I will be trying Astro for the next site.
Milpotel · 1d ago
I switched to Antora but recently shut down my homepage after more than 20 years.
luluthefirst · 1d ago
I don't get it. Stay on the version that you still think is good. Nobody forces you to update. Just don't update Hugo if you don't need its new features? We're talking about a static HTML generator here, not some backend server that needs security updates. Why is it so complicated for people to NOT do a thing?
Proofread0592 · 1d ago
For example, homebrew will auto-update your formulae by default. If you install it with homebrew, you may not have ran `brew pin hugo` and it gets auto-updated.
hn-ifs · 1d ago
> I am only inspired to write a blog post every few months...
> Build failures of my static site, which has maybe a few dozen posts...
> Suggestions for alternatives welcome...
Plain HTML? No build process needed.
jraph · 1d ago
Plain HTML isn't very workable for a blog. You'd have to maintain:
- 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.
PaulRobinson · 1d ago
As others have pointed out, there are good reasons not to do that.
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).
marginalia_nu · 1d ago
The argument for a SSG is to make it possible to e.g. update your header or footer without this turning into a week process of changing thousands of blogposts.
oncallthrow · 1d ago
find -exec sed
jraph · 1d ago
It is definitely possible, and it's possible to copy paste each blog post in a manually-maintained RSS.
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.
AndrewDucker · 1d ago
This is exactly why I prefer a hosted solution.
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.
nunez · 1d ago
All fun and games until they decide that they want to charge you a million bucks a month to pay for the uncontestable added value their AI features (that you don't use and never will use) provide. Or they get bought by private equity or some other faceless entity and basically leave it out to rot, security vulnerabilities and all. Or they take any of the millions of paths to guaranteed enshittification while keeping your blog hostage (until you can spare the eight hours it will take to move your content to something like Hugo!)
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.
privatelypublic · 1d ago
Eg, decap cms?
AndrewDucker · 1d ago
That looks, to me, like a host which requires you to run your own static site generator. If so, then no, I don't want to have to keep that up to date.
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!
zeeZ · 1d ago
What do you gain from compiling it yourself and never updating versus picking the binary you consider done and never updating that?
nunez · 1d ago
Ah, but this is the beauty of open source and, in Hugo's case, being mostly a static site genetator: you're more than free to run ancient versions of Hugo, and no-one can stop you!
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!
TheWiggles · 1d ago
HVM: Hugo Version Manager is an interesting project worth a look.
Helpful for switching between different versions of Hugo.
Sesse__ · 1d ago
Every problem in computer science can be solved with another layer of indirection.
(And in particular, every design failure related to backwards compatibility can be solved with a virtual environment, evidently)
HexDecOctBin · 1d ago
At what point in this ever deepening well of abstractions does one simply use Wordpress?
angulardragon03 · 1d ago
Hugo is a static site generator, so I can host my site anywhere that can serve an index.html.
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
HexDecOctBin · 1d ago
> Hugo is a static site generator, so I can host my site anywhere that can serve an index.html.
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.
noAnswer · 1d ago
He knows that. :-)
figassis · 1d ago
No. Just…no. Replace WP with any other hosted or self hosted solution. Been there. The plugin hell, the security hell, the performance hell…WP has many levels of hell.
tphummel · 1d ago
I’ve been using Hugo for 7 years on multiple static sites. It has been a joy to learn and to use. I struggled with Jekyll previously along a number of the dimensions OP lists - complexity in the tool chain when there are weeks or months between new posts.
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.
ajd555 · 1d ago
I've been using Astro for close to a year, and so far it's been quite enjoyable. I hope it doesn't follow in Hugo's footsteps
omnimus · 1d ago
I think the “stable” straightforward flexible static site generator in JS world is eleventy. Astro is anything but that. It is made with quite specific vision and gets breaking changes all the time.
ajd555 · 1d ago
I luckily haven't felt that, but I'll look into eleventy, thanks!
m82labs · 1d ago
I had a similar situation using Jekyll (before Docker) so I wrote my own SSG, and its compatible with Jekyll frontmatter.
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.
imron · 1d ago
I've been using Hugo for the best part of a decade and I love it, it's fast reliable and does exactly what I need.
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
wodenokoto · 1d ago
I am also looking for an alternative. I write a lot of my posts in Jupyter Notebooks, so I've been tinkering with using Quarto, but I simply don't see what it does for me in this regard. The label on the box says it is great for notebooks to blogs, but it's unclear what it does that makes it great for this.
dragonstyle · 1d ago
Here’s a pretty good summary of the features Quarto includes around publishing a blog.
I love Quarto. I used to use pandoc but Quarto has some nice extras and managed things I would have to manually set up. I much prefer writing plain text with minimal markup in a simple text file rather than fighting with a GUI.
mediumsmart · 1d ago
I found Jekyll some time ago and was done.
altbdoor · 1d ago
I started with Jekyll, and tried out Hugo since there was all the hype.
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.
I've stopped using it for the same reasons outlined in the blog post.
marginalia_nu · 1d ago
Yeah this is my biggest gripe with hugo. There's this inexplicable feature churn that is always breaking stuff for no obvious reason, often it's not even communicated that things will break or how to fix it.
GuestFAUniverse · 1d ago
That's why I stopped even using GitHub pages.
The amount of (pseudo-)maintenance is unbearable.
Seems to counter the idea of a near maintenance free static blog.
akho · 1d ago
Why do they update Hugo if they were happy with past versions? Static site generators can be, you know. Static.
Are you supposed to update these things?
dvh · 1d ago
Fork the version you liked, fix security issues discovered since, remove unused features, clean it up, then rename and publish.
marginalia_nu · 1d ago
I'm not even sure why security fixes would matter in a SSG where you control the input.
ch33zer · 1d ago
Because a malicious ssg could expose private files (private keys etc) at a hidden url only the attacker knows to scan for, drop malware that grants them non-static file access, or really anything that other compromised binaries can do.
cosarara · 1d ago
But we are not talking about a malicious ssg, we are talking about a vulnerable ssg that somehow needs to be patched. Unless your ssg connects to the internet, this is a non issue.
delusional · 1d ago
> Unless your ssg connects to the internet, this is a non issue.
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.
marginalia_nu · 1d ago
If the author of the SSG is compromised, I doubt they'd push fixes for their own exploits...?
iamtedd · 1d ago
(2024)
It's been over 18 months. Has the author switched?
littlestymaar · 1d ago
From the page HTML: <meta name="generator" content="Hugo 0.122.0-DEV">
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.
AbuAssar · 1d ago
imagine if `ls` or `grep` or `cat` kept growing in features and break your memorized commands and parameters every now and then for the sake of improvments!
yea I agree with OP, some software are better done.
Been happily using Astro for the past couple of years.
lawn · 1d ago
My suggestion is to simply build your own static site generator.
It's more upfront work of course, but you don't have to be bothered with the tool changing underneath you.
rendall · 1d ago
I was thinking that a webpack (or similar) config that converts markdown to HTML (or your favorite framework) is good enough and maintainable?
What does Hugo et. al. add on top of that?
empiko · 1d ago
In my experience, a custom setup like you described is the most robust way to do a long term blog. You basically want to decouple from any tech stack, staying with the bare minimum that you need to publish. That's why you can still see custom HTMLs from 30 years ago while many things published in 2010s are already gone.
bananapub · 1d ago
it's definitely annoying, but it doesn't have to be your problem - just pick a version and then use that forever. go is annoying in many ways but this isn't one of them - you should be able to just rebuild a particular Hugo version for ~ever.
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.
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.)
https://www.npmjs.com/package/is-even
Also, check the dependencies :)
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.
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.
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.
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.
I will be trying Astro for the next site.
> Build failures of my static site, which has maybe a few dozen posts...
> Suggestions for alternatives welcome...
Plain HTML? No build process needed.
- 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.
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).
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.
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.
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.
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!
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!
https://github.com/jmooring/hvm
Helpful for switching between different versions of Hugo.
(And in particular, every design failure related to backwards compatibility can be solved with a virtual environment, evidently)
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.
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.
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.
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
https://quarto.org/docs/websites/website-blog.html
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
Are you supposed to update these things?
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.
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.
yea I agree with OP, some software are better done.
It's more upfront work of course, but you don't have to be bothered with the tool changing underneath you.
What does Hugo et. al. add on top of that?