My comment section is static HTML
The comment section here is static HTML. Reading costs nobody anything. #
Posting a comment does take a little more. It’s how I keep guard against bots and spammers, etc.
This blog is a Hugo site. It has a comment section. If you view source on any post with comments, you will find them in the HTML, because they are compiled into the page at build time like everything else. There is no widget, no iframe, no tracker, and no third-party script, and loading a post makes no request to any server but this one. The page does carry some JavaScript (the site search, a few small comforts), but the comments never need it: with JavaScript off you can read every comment and post one.
The shape #
The comments live on a small Phoenix server I run, called Popsicle Boat. Each post has a companion thread there; publishing a post makes one API call that creates the thread and writes its URL into the post’s front matter. That URL is the only coupling between the two systems.
At build time, Hugo fetches each thread’s replies.json and renders the
replies as plain HTML once per post per build, cached, capped
indentation. If the server is unreachable, the build carries on and
renders no comments. The comment system cannot break the blog.
Below the replies is a plain HTML form: a textarea and a submit button,
POSTing to the boat. No script, no cookie, no request on pageview. The
boat walks you through signing in if needed, you confirm, and it sends
you back to the post with #just-posted on the URL. A hidden note
appears via CSS :target to say your comment is on its way. It is: the
boat pings my build hook, and about a minute later the comment is part
of the page. One of the small comforts is that it refreshes for you when it lands. A manual refresh does the same.
Why this shape #
Reading is static. Writing is dynamic. That is the whole idea.
A reader costs nothing and depends on nothing. The page they get here is the page I built, comments included. A writer touches the server once, at the moment of writing, which is the point where a server is not just useful, but like a moat: identity, spam defense, notifications. A comment writer is protected, a website owner (like me) is notified when written to.
The durability falls out for free. The comments are in my generated pages, so they stay with the blog no matter what happens to the comment server. Most comment systems get this backwards: the conversation lives on their infrastructure and your page borrows it at read time, every read, forever.
There is no captcha. Spam defense is the boat’s job and stays invisible: a honeypot, time-to-submit checks, rate limits, and the sign-in step itself. The boat is, to put it simply, the guard at the gate.
The honest costs #
Comments lag by a build. About a minute here on this blog.
Commenting requires an account on the boat. That stops some people. I keep it because a signed name is what makes the no-captcha posture possible.
If the boat is down during a build, that build renders the affected posts without new comments until a later build picks them up. I prefer a page that sometimes forgets to a page that sometimes fails.
If you want this #
The API is written up in one page: create a thread, get replies as JSON, point a build hook at your host. Documented at https://www.popsicleboat.com/for-bloggers/api — you mint your own token, shown once, to you. No one else sees it.