jvalol’s comment system has a server, accounts, spam protection and notifications. Yet when somebody reads a comment on the blog, none of those services has to respond.1

The site is generated with Hugo. Discussions live on a small Phoenix server called Popsicle Boat. Each published post stores the URL of its companion thread. During the build, Hugo fetches replies as JSON and renders them into ordinary HTML inside the page.1

Lower section of the jvalol page describing the static comment architecture
The split is deliberately asymmetric: reading is compiled into the site while writing remains a request to the comment server.jvalol / IRZ capture

The rule is one sentence: reading is static, writing is dynamic.

To post, a plain HTML form sends the reply to Popsicle Boat. The server handles identity, rate limits and spam defenses, then triggers another site build. On this blog, roughly a minute later, the comment becomes part of the published HTML.1

The trade-offs are explicit. Comments do not appear instantly. Posting requires an account. If Popsicle Boat is unavailable during a build, that build can ship without the newest replies.1

But the outage does not break reading. The build continues, and comments already compiled into pages remain there. Earlier stages of the experiment were already trying to avoid making the blog borrow its conversation from an external widget on every page view.23

The architecture reverses a common web habit. The frequent public operation, reading, becomes the least dependent part. The rarer difficult operation, accepting writes without drowning in spam, keeps the server.

This is not the right architecture for every conversation. A large real-time community would find the one-minute lag impressively prehistoric. For a small personal blog, however, it gives comments a different status: they become part of the published document rather than a distant rectangle that still has to exist ten years later for the page to retain its conversation.