Skip to content

Index of /2026/07/27/how-far-from-the-disk/

2026-07-27 08:43  2.8K

How far we got from the disk

In 1995 a URL was a path, and a path was a place on a disk. The listing you got back was produced by walking a directory and printing what was in it. If a file was there you saw it. If it was not, you did not. Nothing stood between the reader and the filesystem except a socket.

Everything built since has been a layer on top of that, and every layer has moved the reader further away.

For the reader

A content management system turns the address into a query. The page has no file behind it. Permalinks are a fiction maintained by rewrite rules, and a useful one, but the address no longer describes a location. It describes an intention.

A single page application removes the document as well. What arrives is a program, and the page is assembled in the browser out of fragments that never existed as a page anywhere.

And now, increasingly, the reader does not arrive at all. A model reads the page and reports back what it said. The final abstraction is the one where the source is never seen by the person who wanted it. Sites are being written for an audience that will mostly be told about them.

For the developer

The same staircase, climbed from the other side. You wrote HTML, uploaded it, and the model in your head matched the disk exactly. Then templates, so the markup would not repeat. Then frameworks, so the templates would not repeat. Then build steps, package managers, containers, orchestration. Each layer arrives as a promise: you will not need to look below this line.

The promises are mostly kept, which is exactly why we took them. Nobody wants to hand edit a hundred files.

But each one quietly costs the ability to answer simple questions. While building this theme I wanted to know why an empty page weighed 20 KB. Answering it meant reading how the CMS turns a JSON file of design defaults into CSS custom properties, and finding the filter that runs before it does. In 1995 the same question was answered by looking at the file.

Now models write the code, and the layer moves again, this time over the code itself. The direction has not changed. Only the speed has.

The obvious irony

What you are looking at is not a directory. It is a database query, rendered through a templating layer, on a language runtime, on a shared host, listing rows that correspond to no files at all. The sizes in the right hand column are character counts, not bytes on disk. The dates are metadata. Parent Directory does not go up anywhere. It follows a taxonomy.

This is the most abstracted possible way to produce the least abstracted possible interface, and there is no way around that. You cannot walk back down the staircase. The building is already up.

What you can do is build something at the top that remembers what the bottom looked like, and be accurate about which one you are standing on.

Parent Directory

Index Of/1.0.2 Server at indexof.kbsr.co.jp Port 443