React: rethinking the frontend
The UI as a function of state — one idea that made a whole class of bugs structurally impossible. Notes from converting a jQuery codebase, one screen at a time.
I'll admit where I started: I saw JSX — HTML in JavaScript! — and closed the tab. Every instinct trained on "separation of concerns" recoiled. Six months later I looked at our jQuery codebase honestly: three thousand lines of selectors and event handlers, where changing a dropdown could break a table two screens away, and nobody could say what the page state actually was at any moment.
The idea that won me over
React's real innovation isn't performance or the virtual DOM. It's a discipline: the UI is a function of state. You don't mutate the page; you describe what it should look like for a given state, and change the state. The moment that clicked, our whole class of "the page got into a weird state" bugs became structurally impossible — not fixed, impossible.
jQuery asks "what should I change?" React asks "what should this look like?" The second question scales; the first one doesn't.
The honest costs, 2016 edition
Nobody should pretend the tooling is friendly right now. Getting webpack, Babel, ES6 presets and hot reload working took me a full day and a config file I fear touching. The ecosystem churns weekly — Flux, then Redux, now MobX, each announced as the answer. My advice after one production project: learn React itself and plain state first; adopt the rest only when you feel the specific pain it solves. Half the "essential" libraries will be gone in two years anyway.
Where we landed
We're converting screen by screen — the interactive, state-heavy pages first, the static ones maybe never. Components have already changed how we scope work: "build the fee summary card" is a task one developer owns end to end, visible in isolation, testable in isolation. It's the first frontend approach I've used that gets easier to reason about as the app grows. That's new.