What React Is (and Why)

Every framework pitch starts with a problem it solves. React's problem was this: as a page gets more interactive — more buttons, more panels that show and hide, more data that changes without a full page reload — manually keeping the DOM in sync with your application's data gets out of hand fast.

The imperative way

Before React (and still, in plenty of code today), updating the UI means writing out every step by hand:

// Toggling a "liked" button, the imperative way
const button = document.querySelector("#like-button");
let liked = false;
 
button.addEventListener("click", () => {
  liked = !liked;
  button.textContent = liked ? "Liked" : "Like";
  button.classList.toggle("is-liked", liked);
  document.querySelector("#like-count").textContent = liked ? "1" : "0";
});

This works fine for one button. Now imagine twenty buttons, a comment count that updates when a comment is added elsewhere, a sidebar that needs to know whether the post is liked, and a "liked posts" list that needs to add or remove this post — all by hand, all kept in sync manually, forever. Every new place that cares about liked is one more spot that can drift out of sync with the rest.

The declarative way

React asks a different question: instead of "what steps update the DOM", what should the DOM look like for the current data? You describe that, and React handles turning it into real DOM changes.

function LikeButton() {
  const [liked, setLiked] = React.useState(false);
 
  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? "Liked" : "Like"}
    </button>
  );
}

There's no manual textContent assignment, no classList.toggle. You said "when liked is true, show this; when it's false, show that" — and every place in the app that reads liked (or whatever data it depends on) stays correct automatically, because React re-runs the description whenever the data it depends on changes. You'll meet useState properly in a later lesson; for now, just notice that the function returns what the UI should be, not a sequence of edits to perform.

Components are the unit

That LikeButton function is a component — the basic building block of a React application. A component is nothing exotic: it's a JavaScript function that returns a description of UI (you'll learn the exact syntax, JSX, in the next lesson) and can be reused anywhere, with different inputs, called props.

An entire React application is a tree of components, nested inside each other, the same way HTML tags nest inside each other:

Why this scales better

The declarative model pays off specifically as an app grows, for two concrete reasons this course will keep coming back to:

• Local reasoning. To understand LikeButton, you only need to look at LikeButton. You don't need to trace through every other file that might also touch the like button's DOM node, because nothing else does — only this component owns this piece of UI.
• One idea, one place. The rule "show 'Liked' when liked is true" is written once. There's no second copy of that rule to forget to update somewhere else in the codebase.

None of this means React is magic, or that it's the only valid way to build a UI — plenty of production software still updates the DOM directly, and for a genuinely simple page that's often the right, boring choice. React earns its complexity budget once an interface has enough moving, interdependent state that "just remember to update everything by hand" stops being realistic.

Try it yourself

Here's the like button running for real. Click it and watch the label change — no DOM query, no manual update, anywhere in the code.

What to remember

• React is declarative: you describe the UI for the current data, not the steps to mutate the DOM.
• A component is a JavaScript function that returns UI and can be reused with different inputs (props).
• An app is a tree of components nested inside each other.
• The payoff is local reasoning: each component can be understood on its own, and each rule about the UI is written in exactly one place.