▲ 79 points
back
76 comments
> 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.
> 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.)
I'd actually recommend Casey/just over a Makefile for this. I love me some Make, but Just is so much nicer.
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.
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?
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.
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.
I don't know about "better" but I like Nikola (https://getnikola.com)
I've used Zola and it gets the job done in a few commands, nothing else I need from it tbh.
I’ve used Zola for years and I love it. Good maintainer, does what it needs to, and it’s
fast.
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.
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
By biggest gripe with Hugo is it doesn't bubble up where problems are.
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.
Did you also do wordpress to jekyll and/or hugo?
If so, huge thanks!
That's exactly my experience with Hugo and why I stopped using it.
What do you use now?
> 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.
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.
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).
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.
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.
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.
Eg, decap cms?
What do you gain from compiling it yourself and never updating versus picking the binary you consider done and never updating that?
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?
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.
HVM: Hugo Version Manager is an interesting project worth a look.
https://github.com/jmooring/hvm
Helpful for switching between different versions of Hugo.
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)
At what point in this ever deepening well of abstractions does one simply use Wordpress?
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.
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
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.
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!
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
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.
I found Jekyll some time ago and was done.
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.
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.
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?
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.
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?
Fork the version you liked, fix security issues discovered since, remove unused features, clean it up, then rename and publish.
(2024)
It's been over 18 months. Has the author switched?
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.
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.