Fractal Responsiveness

I’ve been noticing a pattern lately I can’t unsee.

In software, we treat things and the way we perceive things as two separate jobs. The database holds the thing; the frontend holds a visual tree that someone keeps aligned by hand. Every new screen is a small act of translation, and translation drifts.

I call the alternative Fractal Responsiveness: one graph, many projections, with the client acting as a sensory organ that renders truth at a chosen fidelity instead of maintaining a parallel UI reality. The goal is to make perception derived from data the default, so zoom becomes navigation rather than a pile of incompatible layouts.

Representing a Thing#

When you look at a contact in your phone, that person is a tiny circle with their initials in one place, a list row in another, a full profile in a third. Same person. Three codebases that happen to show the same person, kept in sync by hand. Every app is full of this: the same information rebuilt at every size, like redrawing a map from scratch every time you zoom.

Maps did not make this mistake. Nobody expects Google Maps to label aquarium exhibits while you plan a drive from San Francisco to Monterey. The territory is one thing; the representation changes with scale. Zoom out, detail hides. Same truth, different projection.

Knowledge work software forgot that distinction. When I open fifty Airbnb tabs to pick a conference listing, I am not doing fifty searches. I am trying to close one decision, and the interface makes me be the comparison engine, holding the zoomed-out view in my head while I stare at the zoomed-in one.

We essentially took a document format, hypertext, invented for linked research papers, and forced it to become an application runtime. That created a problem that has haunted us for thirty years:

Truth A: the data. What is actually happening.

Truth B: the DOM. The visual tree we paint on top.

Truth A and Truth B are supposed to agree. They rarely do, not for long. So we invented entire professions to babysit the gap: state management, design systems, sync layers, “source of truth” meetings. The industry normalized maintaining two realities and calling it engineering.

Prior art#

This is not a new itch. Brett Victor’s Up and Down the Ladder of Abstraction framed it for programming. An Adept design talk stitched zoom levels together for Airbnb search: detail page, comparison table, scatter plot, with actions preserved at every level.

The line that stuck with me:

I’m not trying to argue that higher levels are better. Instead, make it easy to move between them.

Spreadsheets got part of the way there. VisiCalc did not automate arithmetic; it stacked recalculation into a grid so changing one cell updated the whole sheet. Maps select representation by scale. Spreadsheets select it by structure. Neither makes you hold both views at once.

What is missing is the insistence that perception should be derived from truth, not maintained as a parallel universe in React.

Fractal responsiveness#

Original HATEOAS, hypermedia as the engine of application state, said the server should tell the client what it can do next, via links embedded in the response. Not a fixed API contract. The representation is the navigation.

I am building toward something adjacent, call it HATEOAS 2.0: the graph tells the client not just what actions exist, but how to perceive any thing at any scale of attention. One entity. Many projections. The client does not invent Truth B; it renders Truth A at a chosen fidelity.

The client is not a brain. It is a sensory organ for the graph, eyes and skin, not cognition. Intelligence stays ambient in the data: what the thing is, how it relates, what changed. The UI is sensation. Vantage is where you are standing; projection is the layout of the room.

Fractal Responsiveness is my name for the sensory grammar. Build the thing once (task, person, event) and let it know how much of itself to reveal. Pull back: dot. Lean in: row, card, page. A thing and a collection of things and a collection of collections behave the same way. Same logic, all the way up and all the way down.

Because everything works this way, you stop building apps and start building views. A calendar is your things, arranged by date. A kanban board is the same things, arranged by status. Not five programs with five copies of your life. One graph, five angles, one zoom dial.

Vantage as a fidelity axis#

In the playground, that zoom dial is a continuous vantage parameter, a CSS custom property (--vantage) and a slider. The UI does not shrink. It changes projection.

A dot is the lowest-fidelity rendering: presence and a hue. Every step up (row, card, page) is a designed answer to what earns screen space at that distance. A dot owes you it exists, and roughly what kind. A row owes you a name and one deciding factor. A page earns the rest.

One record, six presentations, same slider:

dot → chip → row → card → panel → page

The record does not change. The container does.

One live graph of cards switches projection as you climb: dots at the floor, rows in the middle, editable cards at the top. Not four pages. One graph, four views, and the engineering is in what does not change: search and CRUD stay wired while only the projection collapses. Four separate pages would be the easy version. One component graph holding its state constant while the projection changes underneath it is the hard one.

Fractal projections are worthless if Truth A is fake. Vantage is how you perceive. The graph is what you are perceiving.

Fractal Responsiveness names a sensory grammar for knowledge work UIs: build each thing once, derive every projection from the same graph, and treat the client as sensation rather than cognition. The hard engineering is not drawing four layouts. It is holding search, CRUD, and live sync constant while the projection collapses underneath.

When Truth A and Truth B stay aligned, zoom stops being a cosmetic resize and becomes navigation. Vantage tells you where you are standing; the graph is what you are perceiving. That is the whole bet in one sentence.

What’s next#

Page and app-level projections remain sketches in the playground today. Entity and collection demos carry most of the proof. Inset hierarchy is the companion visual grammar: containment-first depth so zoom feels like moving through surfaces, not swapping routes.

Chatbot-first AI UI imagines models generating zoom levels on demand. I would rather the ladder stay navigable without a conversation. AI can help populate or transform levels later. The graph should still be legible when the model goes quiet.

The dot is the floor; the workspace is a dot seen from far enough away. Turtles all the way up.


playground.trellis.computer/fractals · github.com/trentbrew/trellis-fractals-react

Prior art: Adept, Climbing the ladder of abstraction · Brett Victor, Ladder of Abstraction · Trellis playground · Source (React/Next.js)