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.)
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.
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.
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 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).
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!
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 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.
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!
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 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
What does Hugo et. al. add on top of that?
It's more upfront work of course, but you don't have to be bothered with the tool changing underneath you.
Are you supposed to update these things?
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.
