Why React? Components and the UI Mental Model

Here's a real component, running in your browser right now. Change "World" to your own name and watch it update. No setup, no build step, nothing to install.

That's React. A function that returns some UI. Edit the data, the UI follows. The rest of this lesson is about why that one idea (and the model behind it) beat every other way we used to build interfaces.

The problem React actually solves

Before React, building anything interactive meant keeping two things in sync by hand: your data, and the page the user sees. You'd grab an element, read its current state, figure out what changed, and patch it.

Say you've got a counter. The plain-DOM version looks like this:

let count = 0;
const display = document.querySelector("#count");
const button = document.querySelector("#inc");
 
button.addEventListener("click", () => {
  count = count + 1;
  display.textContent = count; // remember to do this, every single time
});

It works. But look at that last line. You are responsible for updating the screen. Forget it, and count quietly climbs while the page shows the old number. Now imagine the count appears in four places, and a "reset" button, and a label that says "you're almost there" once it passes 10. Every one of those is another spot you have to remember to touch, in the right order, whenever anything changes. This is where real apps rot. The bugs aren't in your logic. They're in the wiring between your logic and the screen.

If you've written any of this by hand, you've felt it. (We covered the manual approach in the JavaScript DOM. That's the thing React is reacting to.) The mental load grows faster than the app does.

Components: reusable functions that return UI

React's first move is to package a piece of UI as a function. The function takes some data and returns what the screen should look like. That's a component.

function Greeting({ name }) {
  return <p>Welcome back, {name}.</p>;
}

The thing inside the return that looks like HTML is JSX, JavaScript that describes UI. We'll dig into it properly in the next lesson, but the shape is already clear: data goes in (name), markup comes out. And because it's a function, you reuse it the way you reuse any function, calling it as many times as you want, with different data each time.

<Greeting name="Maya" />
<Greeting name="Aarav" />
<Greeting name="Diya" />

Three lines, three personalized greetings, one definition. If you've written a function that takes parameters and returns a value, you already know this pattern. A component is that, except the value it returns is UI. (If functions still feel shaky, the JavaScript series starts here and is worth the detour first.)

Real apps are trees of these. A <Page> holds a <Header> and a <ProductList>. The list renders a <ProductCard> for each item. The card holds a <Price> and an <AddButton>. You build small, name them by what they show, and snap them together. Same instinct as breaking a program into small functions, applied to the interface.

The declarative mental model

Here's the part that takes a minute to click, and then changes how you think.

With the plain DOM, you write instructions: find this element, change its text, add this class, remove that node. Step by step. That's imperative. You're managing the transition from the old screen to the new one.

React flips it. You don't describe the steps. You describe the result: for this data, the UI should look like this. When the data changes, you don't patch the screen. You just describe what it should look like now, and React figures out the minimal set of DOM changes to get there.

The counter again, the React way:

Click the button a few times. Two things to notice. First, nowhere do we say "now go update the heading text." We say: the heading shows count. React keeps that true. Second, that last line (the "passed ten" message) appears on its own once count hits 10, and vanishes if you could go back below it. We described when it should show. We never wrote code to add or remove it.

That's the whole shift. You stop choreographing changes and start describing states. useState is how a component remembers a value between renders (don't worry about it yet, it gets its own lesson). The point right now is the model: UI is a function of state. Give React the state, and it gives you the right screen, every time, with no sync code from you.

It's just JavaScript

A common worry: React looks like a new language with its own rules to memorize. It isn't. Look back at any example above — components are functions, props are arguments, the markup is JSX (which compiles down to plain function calls), and the logic between is regular JavaScript. The list of cards? That's array.map(), the same method you'd use anywhere:

function ProductList({ items }) {
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

No special loop syntax, no template mini-language. map returns an array of elements, and React renders them. Your variables, conditionals, functions, and array methods are the same ones you already know. React adds a small number of concepts (components, props, state, effects) and leans on the language for everything else. That's a big reason it stuck: there's less to learn than it looks, and what you learn is mostly JavaScript you'd want anyway.

Why it took over

React wasn't first, and it isn't the only good option (Vue, Svelte, Solid are all worth knowing). But it won the mainstream for reasons that hold up:

• The component model scales. Small, named, reusable pieces compose into large apps without the wiring turning to spaghetti. Teams can own different components and not collide.
• Declarative code is easier to reason about. "For this state, show this" is a claim you can read and trust. "Patch step 1, then step 2, then step 3" is a sequence you have to simulate in your head.
• It's a small idea with a huge ecosystem. Routing, data fetching, forms, animation: there's a well-worn library for each, and millions of developers who've hit your exact problem already. That gravity is real.

You don't have to take that on faith. The official React docs at react.dev are genuinely excellent and make the same case interactively. Bookmark them. We'll point back there often.

How this series works

Every lesson in this series runs live, in the editor, the way the examples above did. You won't just read about state or events. You'll click the button, break the code, fix it, and see what happens. That hands-on loop is the fastest way this stuff sticks, and it's the whole reason the lessons live here instead of a static PDF.

What you've got so far: React turns UI into a function of your data. You build small components that return markup, describe what each should look like for a given state, and let React handle the tedious work of keeping the screen in sync. It's mostly JavaScript you already know, with a few new ideas layered on top.

Next we look closely at the markup those functions return, the JSX you've been using without explanation. It has a handful of rules that trip up everyone once, and then never again: React JSX.