That split is deliberate. The marketing surface changes a few times a year and benefits from being hand-tuned. Writing changes weekly and benefits from being plain text in a folder.
Every file in _posts is a Markdown document with a small block of front
matter at the top — title, date, description, tags. On push, GitHub Pages runs
Jekyll, which reads those files, pours them into a layout, and writes plain
HTML into _site. That output is what visitors download.
The practical consequences:
git log.A conventional CMS would put PHP, a database, a template engine, and a plugin surface between a visitor and three paragraphs of text. Each of those is a thing that can be slow, and a thing that can be breached.
The fastest request is the one that never reaches an application server.
For a site whose job is to load quickly and say who I am, that trade is not close.
Static generation is not free of trade-offs. Comments need a third-party service or nothing at all. Search needs a client-side index. Anything genuinely dynamic — a form, say — has to go out to an API.
The contact form on the homepage is exactly that: it posts to a form service rather than to a backend of mine. One external dependency, scoped to one feature, instead of a runtime under the entire site.
The workflow is a file and a commit:
# 1. create the file
touch _posts/2026-09-01-some-title.md
# 2. write it, front matter first
# 3. publish
git add _posts && git commit -m "New post" && git push
GitHub Pages rebuilds within a minute or so, and the post appears on the
journal index, in sitemap.xml, and in the RSS feed without any further work.
That is the whole system. It is small enough to keep in your head, which is the main thing I want from infrastructure that exists to serve prose.
]]>