The tooling vanishes

A website is just HTML, CSS, and JS. But the tools we use to build static sites — the simplest sites there are — drag whole toolchains behind them: node_modules, version managers, dependency updates standing between an edit and a deploy. The site is a plain, durable artifact; the repo that builds it rots underneath.

Garp is what I run instead. It's a fast, minimal static site generator written in Go, and it exists to fill one specific gap: Nunjucks-style templating in a single binary, with no Node toolchain. Hugo is a single binary, but its Go templating is miserable. Eleventy has the templating and the data model I want, but it needs Node and npm. Garp gives me Jinja-familiar templates and an Eleventy-like data cascade and collections, and emits flat static files that deploy to any host.

It isn't a product. There's nothing to download here, no install guide, no community. Garp is a private studio tool — the kit I build and maintain Safaii Studio client sites with — and this site is a wall of the workshop: what the tool is, why it's shaped this way, and proof that it works.

The output is the product

Garp's job is to generate the plain artifact and then get out of the way. Every design decision serves that: the deliverable must be maintainable by any developer with zero garp knowledge, must outlive garp itself, and must never carry studio tooling as baggage.

That's the litmus test every feature has to pass: everything garp leaves behind must survive without garp. If a feature would make the output depend on the tool to function, it doesn't get built.

The build step isn't the problem

The build step is the one thing the web platform never solved — build-time templating, so you don't repeat yourself across pages. The step is inherent and correct. The toolchain is the baggage. Garp keeps the step and eliminates the toolchain: run in CI from a binary committed right in the repo, the build step turns invisible. Edit content, push, the site rebuilds.

Handoff is the point

Every garp site ships as a full source repo with the compiled binary committed alongside it. That's deliberately anti-lock-in: a client can leave — or I can go missing — and any developer picks the site up and builds it with one command. No toolchain to reconstruct, nothing to install. A single dependency-free Go binary makes that handoff more durable than an npm-based repo, not less.

This site is built exactly that way, deployed straight from its own committed binary. The colophon shows the whole rig.

Small enough to read

No magic, no plugins, no unnecessary abstractions. Convention over configuration. Zero client-side JavaScript by default — anything that ships a script is the author's explicit opt-in. Full rebuild every time, because there's no incremental cache to go stale. And the engine stays small enough that any developer — including a future me — can read the whole thing in an afternoon.