React: Why and How?

Draft. This piece originally ran on LinkedIn. Paste the full article here in /keystatic, then turn Draft off. The structure below is scaffolding to delete.

Most "why React" answers stop at the virtual DOM, which has been the least interesting thing about it for years. The real answer is that React made the UI a pure function of state, and everything else followed from that.

The problem it was actually solving

Before components, the unit of change was the element. You held a reference and mutated it, which meant the state of your UI lived in the DOM and in a dozen event handlers, and no two of them agreed.

// The old shape: state is smeared across the DOM and its handlers.
const counter = document.querySelector("#count");
button.addEventListener("click", () => {
  counter.textContent = String(Number(counter.textContent) + 1);
});

The count now lives in a text node. Anything that wants to read it has to parse the DOM.

Rendering as a function

Once your UI is f(state), you stop describing transitions and start describing outcomes.

function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount((c) => c + 1)}>{count}</button>;
}

What you trade for it

• You give up fine-grained control. The framework decides what actually touches the DOM.
• You gain locality. A component's behaviour fits on one screen, and reading it top to bottom is enough to know what it does.

When React is the wrong tool

A static marketing page with three interactive elements does not need a runtime, a bundler, and a hydration pass.

Reach for React when state is genuinely shared and genuinely changing. If neither is true, you're paying for a solution to a problem you don't have.

The short version

React is a bet that describing what the UI should look like is easier to get right than describing how to change it. That bet pays off in proportion to how much state you actually have.