What is React?

A page with a button that counts clicks needs to keep the number in sync with every click. In plain JavaScript, you grab that button's text node, add a click listener, and update the number by hand each time someone clicks. Add a search filter, a shopping cart total, and a modal that opens and closes, and there's a whole set of manual updates scattered through the code now, each one a place a bug can creep in when the data changes somewhere else on the page.

React is a JavaScript library for building user interfaces out of components, and it takes that manual bookkeeping away from you. This chapter looks at what that means in practice: the core idea behind React, where it runs, and how it fits into the library-versus-framework question that comes up early for most people learning it.

Components and the core idea

Here's that same click counter written as a React component:

import { useState } from 'react'

function Counter() {
  const [count, setCount] = useState(0)

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  )
}

This example uses a few pieces you haven't met yet: the markup inside return is JSX, useState is a hook, and onClick is an event handler. The Components and JSX chapters cover that markup, State covers useState in full, and Events covers onClick, so take the syntax on trust for now and follow the shape of the idea instead.

count is the state. The JSX returned by Counter describes what the button should show for that state. Clicking the button calls setCount, which updates count, and React re-renders the button to match. You never touch the button's text directly. You describe it again for the new value, and React works out what changed on the page.

That's the core idea sitting under every React component: you describe the UI as a function of your data, usually called state, and React takes care of updating the DOM to match. A component is a function that returns a piece of UI, and an app is a tree of components combined together, all working the same way the counter above does.

The contrast worth naming precisely is declarative versus imperative. Imperative code, plain DOM manipulation, spells out the steps: find this element, change its text, add this class. Declarative code, what a component returns, spells out the end state: given this data, here's what the button should show. React carries out the steps in between.

Those steps run through a virtual DOM: a lightweight in-memory representation of the UI that React builds from what your components return, compares against the previous version, and uses to work out the smallest set of real DOM changes needed. This exists, and it's fine to set it aside for now. You don't create it, read it, or manage it directly; it's React's internal mechanism for the "make the DOM match" half of the model.

That leaves one mental model worth holding onto for the rest of this handbook: UI = f(state). A component is a function of its data, and hooks, re-renders, and effects are all built on top of that single idea. Most of what looks like a separate React concept later on is really a consequence of this one.

Where React runs

React runs primarily in the browser, rendering components to the DOM. That's the environment this handbook stays in throughout.

React's component model isn't tied to the DOM specifically, though. Other renderers plug the same model into different targets. The best-known example is React Native, which uses React's components and state model to drive native mobile interfaces instead of a web page. It's mentioned here so the name isn't a surprise later. Teaching it is outside the scope of this handbook.

Library or framework?

React renders UI. It doesn't ship routing, doesn't decide how you load data, and doesn't handle server rendering. Those are choices you make yourself, often by reaching for another tool alongside it. That's the practical reason React counts as a library rather than a full framework: it does one job well and leaves the rest to you, rather than owning the whole app the way a framework does.

The kinds of frameworks covers this distinction in full, including where React sits next to something like Next.js, which does add the missing pieces.

JunoUI as a function of state The whole of React comes down to one habit: describe what the screen should look like for the data you have, and let React handle changing it. You don't reach into the page and edit it by hand, you say what it should show, and React catches up. Where it runs, in the browser or somewhere like React Native, is a detail for later. The habit is what matters now.

JunoUI as a function of state Build the habit of writing components as a function of state: given this data, render this. That's what you're doing every time, whether it's a click count on a button or a whole page. React handles the DOM updates so you don't write them by hand, and calling it a library rather than a framework is accurate: it renders UI and leaves routing, data loading, and rendering strategy to you.

JunoUI as a function of state Keep UI = f(state) as the frame for everything that follows. Components are functions of data, the virtual DOM is React's own bookkeeping for turning one render into the next set of DOM changes, and declarative beats imperative here because you stop tracking the update steps yourself. That's why it counts as a library rather than a framework: it stops at rendering and leaves routing, data fetching, and server rendering to whatever you pair it with.

Next up: History and versions, which covers how React got here and what changed release to release.