Which of our actual problems would React solve?

We keep coming back to one move in Kore Nordmann’s write-up of building a sensitive learning-analytics platform without a frontend framework. Instead of asking “why not React?”, the team inventoried the application first, then asked which of their actual problems React would solve — and went down the list and found none.

The app is request/response-shaped: search something, browse a list, open a detail view, follow lineage. For that shape, the biggest cost of the SPA model is that it duplicates the server — state lives twice, rendering logic lives twice, and you end up maintaining an API that exists only to feed your own frontend. HTMX keeps the server as the single source of truth and swaps HTML fragments into the page. One canonical, content-negotiated URL returns either the full page or just the fragment; the URL carries the state, so back, forward, and bookmarking simply work.

This is the restraint we admire: reach for the heavy abstraction only where the application’s real shape demands it — a collaborative editor, a design tool — and otherwise let the platform do the job it already does well. Choosing a stack before looking at the application is how a default quietly masquerades as a decision. It’s a principle we keep close as we build.