Why React Exists

"The primary technical imperative is the management of complexity." — Steve McConnell, Code Complete

You already know JavaScript. You know how to reach into the DOM, change some text, toggle a class. So here is an uncomfortable question: if manipulating the page is that easy, why did the most demanding engineering organisation on earth invent an entire library — and later, a philosophy — just to do it? The answer is that a single DOM update is easy. Keeping ten thousand of them consistent with your data, forever, as five engineers ship features into the same screen every week, is one of the hardest problems in front-end engineering. React exists because that problem was quietly destroying products, and nobody could see it coming until they were already drowning.

Core Concepts

The pre-React world, told honestly

Before React, you built a UI by mutating it. The page was already there; your job was to reach in and change the parts that needed changing. jQuery made this ergonomic and it ran the web for years: $('#cart-count').text(items.length). Grab the element, set its text. Simple, direct, and — this is the trap — manual.

The problem is that a real UI reflects the same piece of state in many places at once. Imagine a shopping cart. When a user adds an item, the cart badge in the header must update, the line-item list must grow, the subtotal must recompute, the "checkout" button must un-disable, and the empty-cart message must disappear. That's one change to your data and five places on screen that must react to it. So you write five DOM updates. Then a teammate adds a sixth spot — a "free shipping" nudge — and updates it in the add-to-cart handler but forgets the remove-from-cart handler. Now the UI lies: the cart is empty but the nudge still glows. No error is thrown. Nothing crashes. The screen is simply, silently wrong.

This is the central disease of imperative UI: state and screen drift apart. Every event handler is a little procedure that must remember to touch every affected part of the page. Miss one and you get a bug that no compiler catches. Multiply by string-template rendering (el.innerHTML = '<li>' + name + '</li>', an XSS hole waiting to happen and a re-render that blows away focus and event listeners), multiply again by a team, and you get the pre-2013 reality: front-ends that grew more fragile with every feature.

React's one idea: UI = f(state)

Here is the entire library in one line: your UI is a function of your state. UI = f(state). You write a function (a component) that takes the current data and returns a description of what the screen should look like for that data. You never write "when the cart changes, update the badge." You write "the badge shows items.length" — as a fact that is always true. When state changes, React calls your function again, gets a fresh description, and figures out the minimal real-DOM changes to make the screen match. The sixth place can't fall out of sync because you didn't hand-wire any of the places; you described the destination and React drives there.

This is declarative thinking — you say what, not how — and it pairs with component-based thinking: you build the UI out of small, self-contained functions that each own a slice of the screen, then compose them like LEGO. A <CartBadge>, a <LineItem>, a <Subtotal>. Each is a pure-ish function of its inputs, testable and reusable in isolation.

The machinery that makes "just re-run the whole function" affordable is the Virtual DOM. Re-touching the real DOM is expensive, and naively re-rendering everything would be slow and would wreck focus and scroll position. So React keeps a lightweight JavaScript object tree — a virtual representation of the UI. When state changes it builds a new virtual tree, diffs it against the previous one (a process called reconciliation), and applies only the differences to the real DOM. You get the mental simplicity of "redraw everything" with the performance of "change only what moved." (We'll unpack reconciliation properly in a later chapter — for now, know it's the reason declarative rendering is fast enough to be practical.)

Seeing the shift

Here is a counter written the React way. Read it, then read the prose after it.

Look at what you did not do. You never grabbed the <p> to update its text. You never toggled the "time"/"times" wording by hand. You never wrote logic to add or remove the celebration message when the count crosses five. You stated three facts — the text shows count, the word depends on count, the message appears when count >= 5 — and React keeps all three true on every click, forever.

The imperative equivalent is a cautionary tale. You'd write document.querySelector('#count') and set its text; then a branch to pluralise "time"; then, on every click, check whether the count just crossed five and either create or remove the celebration node — remembering to remove it if the count ever drops. Three separate places to keep in sync, each a chance to forget. The React version has zero, because there are no "updates" — only a description re-evaluated. That difference, scaled to a Facebook-sized app, is the whole reason React was born.

Common Mistakes

• Thinking React "is the DOM." React is a description layer. When you catch yourself writing document.querySelector inside a component to change what's on screen, stop — you're fighting the model. Change state; let the render reflect it.
• Believing the Virtual DOM is "faster than the DOM." It isn't magic speed — the real DOM is what actually renders. The VDOM's job is to compute the minimal set of real-DOM changes so you can afford to re-render declaratively. It trades a little JS work to avoid a lot of layout thrash.
• Confusing declarative with "no logic." Declarative doesn't mean you write no conditions or loops — you saw both above. It means you express the UI as an expression of state rather than as a sequence of mutation commands.
• Assuming React replaced JavaScript. React is JavaScript. Everything you learned in Volume 1 still applies; React is a disciplined way to organise it around state and components.
• Reaching for React for a truly static page. A brochure page with no changing state gains little from React and pays a bundle cost. React earns its keep exactly where the UI is complex and changes — which is most apps, but not all pages.

Interview Corner

Chapter Summary

• The hard problem in UI isn't making one change — it's keeping a complex screen consistent with constantly-changing state, forever, across a team.
• The pre-React world (manual DOM, jQuery, string templates) did this imperatively: every handler had to remember every affected spot, and forgetting one silently desynced UI from state.
• React's core idea is UI = f(state): you describe what the UI is for the current state; React computes and applies the minimal DOM changes.
• This makes React declarative (say what, not how) and component-based (compose small functions of their inputs).
• The Virtual DOM diffs a new UI description against the old one (reconciliation) and touches the real DOM minimally — the optimisation that makes declarative rendering practical.
• React was created at Meta and open-sourced in 2013 to tame Facebook's UI-sync bugs; JSX and the VDOM were controversial and won.
• React doesn't replace JavaScript or "beat" the DOM on raw speed — it trades a little performance for correctness and maintainability at scale.

Editorial reflection — it's tempting to learn React as a bag of hooks and syntax, a thing you configure. But React is really an argument about how to fight complexity: that the way to keep a growing system correct is to remove the chances to get it wrong. UI = f(state) isn't a slogan — it's a discipline that deletes an entire category of bug by refusing to let you hand-wire the screen at all. Learn React as that idea first, and every hook you meet later will make sense as a tool in service of it.