Comment by susam

I ended up separating out a "plumbing" blog, from the "real" blogs, with no discussion of the tinkering allowed on the real ones - so the plumbing blog grew in details but didn't "count" for the non-meta blogging I was trying to accomplish. A little bit of sleight-of-hand but it worked for me...

> I spend more time tinkering with the blog engine than actually blogging.

You should write a blog about it, like geerlingguy did.

> Only problem I find with self-hosted blogs and certain personalities like mine is that I spend more time tinkering with the blog engine than actually blogging.

I don't see the problem with that ;)

Honestly this is so true. I have a few blogs for various reasons, and the hosted ones are where I post most because it’s so effortless to do. There’s so much less inertia. You can go even further and post by email (I use Pagecord) which removes virtually all barriers to posting.

That said, building your own static site and faffing with all the tech is generally an enjoyable distraction for most techies

https://rakhim.org/honestly-undefined/19/

Babashka now has a built-in markdown library. Babashka now also has a built-in HTML parsing library: Jsoup.

Why does bb carry too much baggage? Because it has useful libraries like the above?

> How do you handle comments in a "static blog"?

The comment form is implemented as a server-side program using Common Lisp and Hunchentoot. So this is the only part of the website that is not static. The server-side program accepts each comment and writes to a text file for manual review. Then I review the comments and add them to my blog.

In the end, the comments live like normal content files in my source code directory just like the other blog posts and HTML pages do. My static site generator renders the comment pages along with the rest of the website. So in effect, my static site generator also has a static comment pages generator within it.

Not the poster, but what I did was to have a CGI script which would receive incoming comments and write them to "/srv/data/blog/comments/XXX/TIMESTAMP.txt" or similar.

The next time I rebuilt the blogs the page "XXX" would render a loop of all the comments, ordered by timestamp, if anything were present.

The CGI would send a "thanks for your comment" reply to the submitter and an email to myself. If the comment were spam I'd just delete the static file.

You could have a _somewhat_ static blog and incorporate something like Webmentions[0] for comments or replies. For example, Molly White's microblog[1] shows the following text below the post:

  Have you responded to this post on your own site? Send a webmention[0]! Note: Webmentions are moderated for anti-spam purposes, so they will not appear immediately.

I find this method to be a sweet spot between generating content on your own pace, while allowing other people to "post" to your website, but not relying on a third-party service like Disqus.

[0] https://indieweb.org/Webmention

[1] https://www.mollywhite.net/micro/entry/202511101848

The way I’ve seen it done is that you render a script tag that embeds a third party comment system (like Disqus).

Third party options (Disqus, for example)

On mine, I don't. Any interactivity is too much hassle for me to worry about wrt moderation etc. I also don't particularly care what random people have to say. If my friends like what I wrote, they can tell me on Signal or comment on the Bluesky post when I share the link.

> just do some string-replacement targeted at a narrow use-case instead of using a complicated templating engine.

A neat little in-between "string replacements" and "flown blown templating" is doing something like what hiccup introduced, basically using built-in data structures as the template. Hiccup looks something like this:

    (h/html [:span {:class "foo"} "bar"])

And you get both the power of templates, something easier than "templating engine" and with the extra benefit of being able to use your normal programming language functions to build the "templates".

I also implemented something similar myself (called niccup) that also does the whole "data to html" shebang but with Nix and only built-in Nix types. So for my own website/blog, I basically do things like this:

    nav = [ "nav"
      [ "h2" "Posts" ]
      [ "ul" (map (p: [ "li" [ "a" { href = "${p.slug}.html"; } p.title ] ]) posts) ]
    ]

And it's all "native" Nix, but "compiles" to HTML at build-time, great for static websites :)

> Your wife’s Python version is quite impressive.

Thank you. That was, in fact, the inspiration behind writing my own in CL.

Thank you. My current home page has about 70 entries. The HTML size is about 7 kB and the compressed transfer size is about 3 kB.

I created a test page with 2000 randomly generated entries here: <https://susam.net/code/test/2k.html>. Its actual size is about 240 kB and the compressed transfer size is about 140 kB.

It doesn't seem too bad, so I'll likely not introduce pagination, even in the unlikely event that I manage to write over a thousand posts. One benefit of having everything listed on the same page is that I can easily do a string search to find my old posts and visit them.

Raises an interesting point.

How large does the canvas need to get before pagination makes sense?

Modern websites are enormous in terms of how much needs to be loaded into memory- sure, not all of it is part of the rendered document, but is there a limit to the canvas size?

I'm thinking you could probably get 100,000+ entries and still be able to use CTRL+F on the site in a responsive way since even at 100,000+ entries you're still only about 10% of Facebooks "wall" application page. (Without additional "infinite scroll" entries)