> 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 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.
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.
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
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.
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!
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.
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.
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.
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
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.
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 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.
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 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.
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 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
reply