I've been using Hugo as well. I used Pelican (Python port of Jekyll) for a long time, but Hugo is so much more performant and has a larger ecosystem at this point.

The main downside is that the Hugo documentation is sometimes terse and snarky.

With regards to performance, I used Hugo like 3 or 4 years ago now, and it was insanely fast!

Compared to really sluggish build times with Jekyll/Ruby it was incredible!

Some sites went from 10s of seconds to what felt like instant build!

However, with new versions of Ruby and M1 Macs, I dont notice build lag in Jekyll anymore!

And overall, I much preferred Jekyll and the way it structured sites, template and includes! :-)

I switched my blog from Jekyll to Pelican recently after getting sick of constant ruby package versioning issues. It’s pretty nice, though maybe not as good for getting your site to appear on google search

My work has moved largely from Ruby to JS, so I've been enjoying Gatsby! It's probably overkill for simple sites, but I like how customizable it is.

For React-based projects, I would advocate for Next.js…but yeah, unless you know you need React for very specific reasons, it's definitely overkill. =)

Next.js is cool, but afaik takes a server, right? Gatsby is nice because you get React for component re-use + styling, but it builds into regular HTML+JS files and can live on (abundant, free) static site hosts.

It's primarily used with a server, correct. However, you can use `next export` which will generate only static assets (like HTML, JS, and CSS). Certain features aren't available that require a server (like i18n routing) but you can still do a lot!

Jekyll. It ain't broke, so why fix it?

I was just researching static site generators and the ones that piqued my interest were:

* Hugo

* Eleventy

* Zola

Note that I excluded ones that output SPAs since I just want plain old hand-written HTML.

Jekyll’s biggest hurdle for me was installing a Ruby environment.

I should have added that static site generators are ranked by popularity (i.e. stars) here:

https://jamstack.org/generators/

I built a blog with metalsmith years ago. I decided to resurrect it recently and, though I tried, I could not find anything to beat its simplicity. A JSON file provides the flow, plugins do the work. Only thing against is that the plugins encourage developers to create multiple and largely undesirable node dependencies.

I use hexo. It’s node and not super popular, but it does what I need and I’ve built my workflows around it so alost everything is done by cli (bash, imagemagick and hexo).

It can be seen here:

https://chrisbergeron.com

I wrote my own static generator in Python using Jinja2. It's very minimal but it works well enough for me. It may not scale well when there are hundreds/thousands of files but it will take a long time for me to hit that.

Instead of a traditional static site generator, put some content at /colophon that lists the transformations that need to be applied to produce the desired output, and then have a machine perform those steps.

This "machine [that] perform[s] those steps" sounds exactly like it is a static site generator.

Yes, that is the intended meaning. This static site generator is non-traditional; it should live as first-class content on one of the pages of the site it outputs. This is not the way traditional static site generators work, although they should.

Sounds like a fucking weird place to keep it, so I don't think they should.

Not weird to suggest that an organization's website should serve as that organization's knowledge repository. Weird is the tradition of building out websites that are little more than Potemkin villages for the entity they represent. A Engelbart-style DKR <https://www.dougengelbart.org/content/view/190/> is certainly not bizarre as willingly participating in the inconvenience of relying on out-of-band documentation like a README that exists only in the source repository that lives on, say, GitHub, and a set of scripts/binaries that you have to download/install/configure separately and whose esoteric conventions you will have forgotten by the next time you try to update the site a year and a half later <https://corytheboyd.com/posts/2020-03-09>—or worse, you find those tools no longer work, even though you do remember how to use them.

Hugo. I did find creating my own theme to be a bit of PITA due to the lack of documentation but once I got over that hump it's smooth sailing.

Ive been using Hugo

I use Pandoc and a few lines of nodeJS code.

Publii CMS for simple static blogs and sites in which clients will manage the content themselves.

Template::Toolkit (Perl) and Middleman (Ruby).

I switched from jekyll to elder.js.