Yes, it is, specifically in ease of use of the static site generator itself, especially compared with a Python or Ruby one. (Node things tend to be more amenable to easily reproducible builds.)
From experience, I say that installing Python or Ruby static site generators (Hyde and Jekyll specifically I have in mind) starts out markedly harder, and tends to get steadily harder over time, particularly if you don’t ride the upgrade treadmill¹, whereas the likes of Hugo (Go) and Zola (Rust) are a single binary that you just download and run, and it’ll continue to work forever, and when you switch computers you can just copy or download the binary again and it’ll still work.
This difference concretely saved substantial quantities of time for redoing Fastmail’s website last year in Zola: once it genuinely was just “download Zola 0.8 from such-and-such a location and run `zola serve`”, a few people that would have given up on setting up a Jekyll or Pelican or similar environment, and instead gone with a longer “try modifying it, deploy it and see what happens” or “ask someone else to do it” approach, instead did just download the single binary and use it, because it genuinely did Just Work™.
If it’s hard (here probably meaning “takes longer than five minutes of effort”) to get an editing environment going for your blog or website or whatever, you will abandon your website sooner or later, for a cause that you wouldn’t if you were using one where it was easy.
So I say: prefer a single-binary for your occasionally-updated website, so that it’s your fault when you abandon it, rather than the SSG’s!
___
¹ For example: I used Hyde for the previous iteration of my personal website, and last time I tried to spin up a fresh build environment for it, I genuinely failed—I knew what I was doing, but a couple of packages in there would no longer build. Admittedly Hyde is abandoned and you’re not likely to have quite such trouble on an actively-maintained project, but still: treadmills, and processes that you can’t be confident in.
not really. although hugo is pretty established, too. for a personal blog, i'd just pick one and run with it. getting stuff out is more important than the "right" generator.
(that said, personally, i prefer the runtime hackability of pelican, and i don't find the speed of generation to matter much under 200 posts)
From experience, I say that installing Python or Ruby static site generators (Hyde and Jekyll specifically I have in mind) starts out markedly harder, and tends to get steadily harder over time, particularly if you don’t ride the upgrade treadmill¹, whereas the likes of Hugo (Go) and Zola (Rust) are a single binary that you just download and run, and it’ll continue to work forever, and when you switch computers you can just copy or download the binary again and it’ll still work.
This difference concretely saved substantial quantities of time for redoing Fastmail’s website last year in Zola: once it genuinely was just “download Zola 0.8 from such-and-such a location and run `zola serve`”, a few people that would have given up on setting up a Jekyll or Pelican or similar environment, and instead gone with a longer “try modifying it, deploy it and see what happens” or “ask someone else to do it” approach, instead did just download the single binary and use it, because it genuinely did Just Work™.
If it’s hard (here probably meaning “takes longer than five minutes of effort”) to get an editing environment going for your blog or website or whatever, you will abandon your website sooner or later, for a cause that you wouldn’t if you were using one where it was easy.
So I say: prefer a single-binary for your occasionally-updated website, so that it’s your fault when you abandon it, rather than the SSG’s!
___
¹ For example: I used Hyde for the previous iteration of my personal website, and last time I tried to spin up a fresh build environment for it, I genuinely failed—I knew what I was doing, but a couple of packages in there would no longer build. Admittedly Hyde is abandoned and you’re not likely to have quite such trouble on an actively-maintained project, but still: treadmills, and processes that you can’t be confident in.