The filesystem is the best CMS. For my static blog I just stick to a file naming format like ~/www/blog/2020-10-17-1.html and then assemble post indices with shell and variations for monthly indices. The RSS feed generation is a 100 line perl script though.

    ~/www/blog/ $ ./recentblogposts.pl; ls -v 2020-*.html | tac | xargs cat > blog-2020.html

This is my 103 lines python version: https://github.com/cristiandima/scribe. I wrote it about four years ago for my own blog and I still use it to this day.

It does however depend on a few libs and comes with separate html template files for a theme so I am not exactly sure where I stand on the golf course.

Mine is 60 lines of js; the markdown library does most of the work.

https://roadtolarissa.com/literate-blogging/

The most minimal I can muster is 3 lines of Bash:

    for filename in ./posts/*.md; do
        pandoc -s -c style.css $filename -o outputs/$(basename $filename md)html
    done

This can get pretty pedantic. Where do you draw the line between what is the blog generator and the tools required to do it when counting the number of lines of code? One could easily argue in this case you might want to be counting the lines of code in pandoc, not this bash script.

That said, I do think this is the way to go, using a popular and generic tool (notably that you do not have to maintain) to accomplish a specific task. And more importantly, composing utilities together in a succinct and efficient way.

Also, if you used semicolons, or xargs with a pipe, you could make this one line :) newlines can be pretty arbitrary, I wonder if there's a better measurement for simplicity, like branches or statements/expressions.

In that case, here it is in one line, producing byte-for-byte identical output to the snippet above:

    pangeadoc -c style.css ./ -O ./_site

(pangeadoc, of course, is a fork of pandoc that when invoked as above behaves exactly the same as those "3 lines of Bash".)

damn, that's not a bad effort, I like it. But it does sort of feel like cheating ;)

Mine is about 140 lines of bash, and I don't /think/ i'm using anything that isn't part of coreutils.

The real story here is not the 60 lines, but the literate programming style used for it.

Aside from that, this approach is very similar to Marijn Haverbeke's (the CodeMirror author) generator, although your 60 lines does lean more heavily on third-party packages.

https://marijnhaverbeke.nl/blog/heckle.html

Mine is 4 lines, although it would be trivial to make it shorter. Here it is, although I'm actually working on migrating over to Hugo because it has some nice features that would be a pain to implement myself

  for filename in pages_md/*.md; do
   basename=$(basename "$filename" .md)
   pandoc "$filename" -f markdown_github -t html -o "pages/$basename.html"
  done

1 line of Perl counts for 5 lines of Python, so you're actually behind on the golf course.

Interestingly OP's project includes equivalent Perl and Python implementations and his Python version is actually shorter, I did not expect that.

That seems like a lot of unnecessary maintenance to me.

I ported the program to Python when the Perl version was already fleshed out a bit. Keeping them in sync hasn't been that hard. After each update I run both versions on the same input file (resulting in my blog https://plurrrr.com/) and check with meld if there are any differences. This works very well. I am only a little worried that the Python code might contain some Perl-isms.

I disagree. It does a lot to help reliability and to find bugs.

It also means you have a completely decoupled backup system should anything go wrong with the primary.

I'm aiming to have at least one redundant component for every piece in the system I'm writing.

I did not notice that, thanks for pointing it out.

It started small but then I added an RSS feed (it already had JSON somewhat from the start) and various calendar views. Also some code was added to rewrite an image followed by text to a figure + figcaption to make it more semantic and easier to style.

My ~750ish one to split the difference.

https://sr.ht/~jpgleeson/piaine/

I do think this is one of the most enjoyable projects I’ve ever done.

Same here. I was happy to find a small bug in the code so I could work somewhat more on it.