Tools · Method

How we choose a tool

Four questions, asked in order, before anything is installed.

OVRS Editorial30 August 20263 min read

What does it replace

A tool that adds a capability is easy to argue for. A tool that replaces something is easier to judge, because you can name what leaves with it.

If nothing leaves, the answer is usually that the job was small enough to write out plainly, and the plain version is the one that still works in three years.

Who owns the job

Two libraries that both believe they own the same thing will eventually disagree, and the disagreement always surfaces as a bug that makes no sense — a page that scrolls twice, an element removed from a parent that no longer holds it.

So every job gets exactly one owner, written down. One scroll engine. One image pipeline. One place where colour is defined. When something breaks, the question of whose fault it is has already been answered.

What does it cost the reader

The cost is not measured on a build machine. It is measured on a phone, on a connection that is doing something else at the same time.

Anything that only renders on the client has to justify why the server could not do it. Anything decorative has to justify itself twice, because decoration is what a slow connection drops first and what a reader notices last.

How does it leave

The last question is the one most often skipped: what does removing this look like.

A dependency that has spread into every component cannot be removed, only endured. So the ones we keep sit behind a boundary — one module, one setup function, one teardown — and the teardown is written at the same time as the setup rather than after the first thing breaks.