Static sites are still the right default

A static site is a folder of HTML. Everything else is optional.

That is the whole pitch, and it has aged surprisingly well. Everything added
on top of a static site since 2015 has been an attempt to make dynamic
behaviour feel cheap, and a great many of those attempts have been a bad trade.

## What you give up

Honesty first, because the trade is real:

– **No per-request logic.** No server-side rendering based on the visitor.
– **Content changes require a rebuild.** Unless you bolt on a CMS, and even
then the rebuild is a rebuild.
– **No session state** without a third-party or edge runtime.

## What you get

The costs above are real. The offsetting benefits are fewer and larger:

### Latency

A static file can be served from the edge. There is no cold start, no query
planning, no serialised database connection in the request path. The time
between a DNS lookup and the first byte is essentially the network.

### Failure modes

A static site has one failure mode: the server is not running. There is no
database to exhaust, no connection pool to saturate, no memory leak that grows
with traffic. This property is worth more than it sounds like, because it is
the difference between “the site is down” and “the site is down and we do not
know why”.

### Cost

Static hosting is close to free, and a small VPS running a container that
rebuilds on push costs a few dollars a month.

“`sh
# The entire deploy. There is no second half of this.
git push
“`

## When it is the wrong choice

Three cases, none of them hypothetical:

1. **Content changes by the minute, from many people.** A news desk, a
changelog, a status page. You want editorial workflow and instant
publishing, which means a system that is not “run a build”.
2. **The page is genuinely different per visitor.** Personalised pricing,
authenticated dashboards, anything behind a login.
3. **Interaction is the product.** A real-time editor, a collaborative canvas.
None of this is a blog.

If you are reading this on a blog, you are almost certainly in the first
category’s opposite.

## The middle path

The useful middle is to keep the *pages* static and push the *dynamics* to the
client. A search index, a theme toggle, a table of contents that knows where you
are — none of these need a server. They need about forty lines of JavaScript
that runs after the HTML has already painted.

The test is simple: if the page is still complete and correct with JavaScript
disabled, you are doing it right. If it is a blank rectangle, the server should
have been rendering it.