The site you are reading, and the thing that generates it.

Why hand-write it#

I was going to use Astro. What changed my mind was not dependency squeamishness but a specific observation: this site's SEO ceiling is set entirely by the HTML it outputs, and has nothing to do with what generated that HTML. And the HTML a static blog needs is far less complex than a build toolchain.

So the scope defined the tool rather than the other way round. If all I need is "turn Markdown into correct HTML", Node's standard library already covers it.

What it actually is#

A CommonMark subset renderer, covering the syntax I actually write
A YAML front-matter parser that supports only the shapes I actually use, and raises on anything else rather than guessing
One route table every URL derives from — pages, Markdown mirrors, feeds, sitemap
One head() function that owns every crawler-visible tag
A set of schema.org builders where each entity has a stable @id and is defined exactly once site-wide

Constraints#

Zero JavaScript output. Table of contents, language switching, and dark mode are all server-rendered or pure CSS.
Build-time validation. A missing description, an over-long title, a future date, a second H1 in the body — the build fails rather than shipping it quietly.
Post-build audit. A separate script checks every page for canonical collisions, hreflang reciprocity, internal links that resolve, JSON-LD that parses, and images with alt text and dimensions.

What it costs#

The obvious one: no incremental build, no HMR. A full rebuild is about 100ms, so neither is needed yet. When it is, the content is plain Markdown and moving to Astro is a day's work.

The second: I maintain the Markdown renderer myself. Three edge cases have already forced changes to it. That cost is real — it is just currently lower than maintaining a dependency tree.