Interactive essays need state, not screenshots

Interactive essays are good when the reader can change the system.

A screenshot shows one answer. State shows the thing that produced it.

That is why interactive essays work: the reader can change the input, see the system respond, and check whether the explanation still holds. The controls should be few and tied to the concept, and the current state should be visible enough to inspect.

If the essay cannot return to an interesting state later, it is probably pretending to be interactive instead of teaching through interaction.

maintenance is part of the choice

Interactive essays cost more than static prose.

They can break when dependencies change. They need responsive layout. They need keyboard and screen-reader consideration. They need defaults that still work when viewed on a phone. They need tests or at least smoke checks. They need graceful failure when JavaScript does not load.

That means interaction should earn its place.

If the concept is linear and the state does not matter, write prose. If one image explains it, use the image. If a small table is enough, use the table. But if the reader needs to manipulate the system to understand it, build the interaction properly.

The worst version is an interactive-looking essay that is really a screenshot with a fake control surface. That teaches the reader to admire the artifact instead of interrogating the system.

the point

Interactive essays are at their best when they make the author’s claim falsifiable.

The prose says a parameter matters. The reader changes it. The system responds. The failure appears. The explanation has to survive contact with the controls.

That is why state matters more than screenshots. State lets the reader participate in the argument.