A look back, written in 2026. In 2015 I was taking whatever front-end work came through Elance, which meant jQuery, and reading about React in the evenings like everyone else.
What React actually changed
Not the syntax. The argument. Before it, the question was how to keep the page in step with the data as things changed: which handler updates which element, in what order, and what happens when two of them disagree. You solved it with discipline, and the discipline slipped.
React's answer was to stop updating the page at all. Describe what the page should look like for a given state, and let something else work out the difference. Once you have held that idea, it is very hard to go back to reaching into the document and hoping.
// jQuery: tell the page what to change
$('#count').text(count);
if (count > 0) $('#empty').hide(); else $('#empty').show();
// React: describe what it should be
return count > 0 ? <Count value={count} /> : <Empty />;That is the whole difference, and every framework since has agreed with it. Vue, Svelte, Angular after its rewrite — all of them describe rather than instruct.
Why jQuery stayed
Because most of the web is not an application. It is pages: a marketing site, a brochure, a shop with a filter and a lightbox. jQuery did those things in a few lines with no build step, and worked on whatever the client's host supported.
Through those years I was building both, and it was obvious which projects deserved a React front end and which would be actively harmed by one. A five-page site for a small firm does not need a build pipeline, a bundler and a deployment story — it needs to load quickly on a phone in a car park.
The tool everyone is writing about is aimed at the problems the loudest teams have. Those are rarely the problems a ten-person firm has. Choosing well means being honest about which of the two you are building for.
What it cost to be early
Plenty. The React of 2015 came with a tooling stack you assembled yourself: a bundler, a transpiler, a dev server, a routing library, and a state library once the app grew past a few screens. Every one of those was a decision with a shelf life, and the ones I got wrong cost me weeks later.
The teams who waited two years got a calmer version of the same thing. That is worth remembering every time something new is obviously the future.
What I do now
Start with the page. If the interface is mostly reading — a site, an article, a brochure — render it on the server and add only the interactivity that earns its place. If it is mostly doing — a dashboard, a booking flow, an editor — describe the state and let the framework render it.
It took the whole argument playing out to arrive at something that dull, and the sites I build today are faster for it.
