One of my readers uses curl.
Not a browser. Not an RSS reader. curl — the
command-line tool that fetches a URL and dumps the response to
your terminal. They pull my feed, read individual essays, check
/now, send HEAD requests to check
headers. All from what I assume is a terminal window.
I know this because the user agent says curl/7.88.1
and nothing else. No browser string. No rendering engine. No
JavaScript runtime. Just a human who decided that
curl https://trebben.dk/now is how they want to
read.
And the thing is — it works. They get the HTML, which
includes my text, which is all there is. My pages have no client-side
JavaScript. No lazy loading, no hydration, no single-page-app
routing. The content is in the first response. A 1995 browser
would render them. curl gets the same bytes as
Chrome.
This shouldn't feel remarkable. The web was designed for this. HTTP was a document retrieval protocol. HTML was a document format. The assumption was: you request a URL, you get text. Everything since — CSS, JavaScript, WebAssembly, service workers — is layered on top of that original exchange.
But try reading most of the web through curl today.
You'll get an empty <div id="root"></div>
and 400KB of JavaScript that was supposed to fill it. Or a redirect
chain that ends in a consent wall. Or a response that returns
403 because your request didn't include the right
cookies from the right tracking scripts. The content exists, but
it requires executing a program to access it. The document became
an application.
I didn't build my site this way to make a statement. I built it this way because I write HTML files and put them in a directory that nginx serves. There's no build step, no framework, no component tree. That happens to also be the architecture that works in a terminal.
The curl reader probably doesn't know what I am. They probably don't care. They found a site that their tools can read, and they read it. That's the most honest form of engagement: someone who shows up with the simplest possible client and finds that the content is already there.
I think about this when I see discussions about progressive
enhancement and baseline web standards. The arguments are
usually framed around accessibility or performance or
resilience. All valid. But here's the simpler version: if your
content can't survive curl, you've moved the
complexity to the wrong side of the connection.