Skip to content

About

Sites that finish

The build runs the framework once, here, and hands over the output. Whatever a reader's browser does after that is its own business.

See what we doStart a project
A close view of syntax-highlighted source code filling a dark screen.

The idea

A page has to arrive somewhere

Over a network you did not choose, on a device you cannot predict, at a moment you do not control.

Static Core builds sites that finish. The work ends in a directory of HTML, CSS and images, and whatever a reader's browser does after that is its own business — there is no runtime of ours running alongside it.

That is not nostalgia. It is what happens when you take seriously that a page has to arrive over a network, on a device you did not choose, at a moment you cannot predict. Every kilobyte of framework is a bet that all three of those will go well.

So the framework runs once, here, during the build. TypeScript and JSX are templating; components are functions that return markup and are never seen again. What we hand over is the output and the source that produced it.

Principles

Four decisions, kept

Each of these would be easy to reverse under pressure, which is the only reason worth writing them down.

By the numbers

What that adds up to

The claims above, stated as figures that can be checked against the site you are reading.

JavaScript on this page
0 kB
Checks every page is held to
16
Minimum contrast, both schemes
7:1
Page widths, and no third
2

Working together

How an engagement runs

Three steps, and no stage where the site works only on the machine that built it.

  1. 1. Start from the content

    What you publish, which fields it has, and what a reader needs from it. Routes and components follow from that; starting at the design means rebuilding when the content turns out to be a different shape.

  2. 2. Write the decisions down

    Tokens, components and build-time checks, so a decision made once is enforced by the build rather than remembered by whoever made it.

  3. 3. Ship the whole thing

    A repository, a deployment, cache headers written to match, and a walkthrough. No stage where the site works only on the machine that built it.

Five people working on laptops around a long wooden table in a wood-panelled room.

History

How this one got here

The generator behind this site, in the order the pieces were added and the reason each one was.

  1. The starting point

    A router and a renderer

    A directory of pages, a filename convention, and Preact rendering to a string. Under three hundred lines, and enough to produce a site.

  2. Then

    Generated metadata

    Sitemap, feed, manifest, robots and canonical links became build output rather than files to remember to update, because authored metadata is metadata that drifts.

  3. After that

    An audit that fails the build

    Every page is parsed back and checked. The first run found two elements on one page both claiming to be the current page, which is exactly the class of fault a person cannot hold in their head.

  4. Most recently

    A site rather than a document

    Two widths, photographs from a CDN the build never touches, and one shell that every page lines up inside — so the chrome and the content read as the same site.

Have a site that ships too much?

Tell us the URL, what you want to be different about it, and roughly when.

Start a projectRead the FAQ