What React Is

The opening chapter of this book. From Chapter 2 onward you start writing code in earnest. Before that, this chapter goes over why React again, how this book differs from other introductory books, and what runs through Chapters 1 to 34.

Part 4 (Modern Next.js), Part 5 (Operations, Testing, Deploy), and the Part 6 fullstack capstone are all contained inside the final section of this chapter, “What this book covers.” So this chapter carries more weight than a typical “Part 1 Chapter 1”. Take it slow and follow along.

Why React again? #

The same site has the old React Basics series, 15 parts. It is a good place to learn the fundamentals — components, props, state, useEffect — for the first time, and it stays up as-is on the site. That series is in fact hooks-based, but the React ecosystem has moved much further since. A few of the bigger shifts:

• App Router and Server Components (Next.js 13~15, React 19) — the model has moved from page-level routing to one where layout / loading / error / not-found are first-class. And components that fetch data directly on the server became the default.
• Server Actions (React 19) — you can put a server function directly inside <form action={fn}>. The fetch + API route + revalidate cycle collapses into a single function.
• The use() hook (React 19) — a hook that can unwrap both Promises and Context. It is also the only hook where conditional calls are permitted.
• React Compiler (React 19) — automatic memoization landed. The need to reach for memo / useMemo / useCallback by hand drops accordingly.
• ref as prop (React 19) — the model changed so that ref is just received as a prop, without forwardRef.
• TypeScript first — what was an “option” in 2018 ~ 2020 has become the de facto default. Almost every library ships types alongside.
• Vite + pnpm — create-react-app is officially deprecated. Vite has become the standard for new projects.

Both the toolchain and the underlying primitives have shifted. This book starts on top of those shifts from page one.

The old series stays as-is. The procedure for moving old React (class components · Pages Router · Redux-only · componentDidMount) to the modern style of this book is collected separately in Appendix A: Migrating Old React Code. If you are coming from the old series or an older codebase, read this book starting from Chapter 1 and keep Appendix A by your side whenever you need it.

How React was born #

React was created in 2011 by Jordan Walke, a software engineer at Facebook. It was first applied to Facebook’s News Feed feature and then released as open source in 2013.

At the time, Facebook was struggling to manage an increasingly complex UI. When a user posted a comment, the counters around the screen, the notification badges, and the state of the feed all had to update consistently and immediately, but with the imperative DOM manipulation of the day it was very tricky to update every one of those parts without missing any. React was born specifically to solve “the problem of keeping a complex UI consistent.”

In the ten-plus years since, React has grown from a pure UI library into a fullstack model (RSC + Server Actions). Part 4 of this book covers that expanded territory.

A library or a framework? #

People often say “the React framework,” but strictly speaking React is a UI library. It does not force fullstack features like routing, data fetching, or form handling on you; it focuses solely on “drawing user interfaces.”

That minimalist philosophy is exactly what allowed an ecosystem of meta-frameworks to grow on top of React. The most famous is Next.js, and others include Remix, Astro, and TanStack Start. Before moving to Hugo, this site (schoolofweb.net) also ran on top of Next.js.

This book gives Part 4 over entirely to Next.js (App Router). Not because it is a “React only” intro book, but because the area where React is actually used — meta-frameworks for fullstack — should fit inside a single volume.

The five core traits of React #

Let us boil React’s core traits down to five. Chapters 1 ~ 34 of this book cover these five in depth, one at a time.

1. Component-based #

React starts from breaking the screen into small pieces. Buttons, inputs, cards, headers, a single line of a comment. You turn every one of these into a self-contained unit called a component, then snap them together like Lego bricks to build the whole screen. The same component can be reused in many places, and each component is responsible only for its own behavior and appearance.

In this book, Chapter 4 (Components and props) walks through building your first component, Chapter 17 (Typing props and children) sharpens its interface with TypeScript, and Chapter 24 (Server vs Client Components) takes on the new two-way split of server / client.

2. Declarative #

When you build a UI with plain JavaScript, you have to command the screen step by step: how to change it. React goes the other way. You only declare what you want to show, and React figures out how to make the screen look that way.

For a simple example, imagine the feature “every time a button is clicked, a counter goes up by 1.” Plain JavaScript:

let count = 0;
const button = document.querySelector('#btn');
const display = document.querySelector('#count');

button.addEventListener('click', () => {
  count += 1;
  display.textContent = count;
});

The same feature in React:

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

No direct DOM manipulation. When the count state changes, React updates the corresponding part of the screen on your behalf. You do not command how the screen should change step by step; you only declare what it should look like. That is what declarative means.

This book digs into the exact model for the code above in Chapter 5 (useState), and revisits the type inference of useState<number> in Chapter 18 (typing hooks).

3. Virtual DOM #

One of the secrets behind React’s speed. The real browser DOM is expensive to touch directly. React keeps a virtual DOM — a tree of plain JavaScript objects — in memory; when something changes, it compares the new virtual DOM with the previous one (reconciliation) and then only applies what actually changed to the real DOM.

This book takes a direct look at how the reconciliation algorithm uses key in Chapter 8 (Lists and key), and in Chapter 14 (Performance) we cover the tools that reduce the cost of virtual DOM comparison — memo, useMemo, and the role of React Compiler — head on.

4. One-way data flow #

In React, data always flows in one direction, from parent component to child. The child cannot freely change the parent’s data; it can only signal intent through a function the parent explicitly passed down. The predictability of this flow makes debugging easier, and it makes it easier to track the origin of data even in larger applications.

This book looks at how this model plays out in sharing data between sibling components in Chapter 11 (Lifting state up), and discusses where to break the flow when the cost of one-way flow gets too high in Chapter 12 (useContext). Then in Chapter 27 (Server Actions) we see how the client → server one-way is expressed in the new model.

5. A huge ecosystem #

One of React’s strongest assets is the rich ecosystem around it. Routing (React Router, Next.js), state management (Zustand, Jotai, Redux Toolkit), server communication (TanStack Query, SWR), auth (Auth.js), UI kits (shadcn/ui, MUI, Chakra UI). Whatever the problem, there is already a tool for it, and a lively community keeps producing new answers.

Part 5 (Operations, Testing, Deploy) of this book covers testing (Vitest + Playwright), performance (Web Vitals), auth (Auth.js), deploy (Vercel / Cloudflare Pages), and observability (Sentry / PostHog). We also lay out the judgment criteria — “which tool to pick for which problem.”

React in 2026 — toward a server-first model #

The five core traits above have barely changed since 2011. What has changed significantly is the way React is used on top of them.

• 2013 ~ 2018: client SPA was the standard. Every component ran only in the browser, and data came in through fetch inside useEffect.
• 2018 ~ 2023: hooks and Next.js Pages Router became the standard. Some SSR was introduced via getServerSideProps / getStaticProps.
• 2023 ~ present: the era of App Router + Server Components + Server Actions. Components that fetch data directly on the server are the default, and client components are placed only where interaction is needed.

This shift is not a simple tooling change. The very meaning of “building a fullstack app in React” has changed. Chapter 22 in Part 4 (Why Next.js and Server Components) revisits this inflection point one more time. And Chapter 28 (React 19 features in one place) bundles together the React 19 features that made that inflection possible.

What you can build with React #

React covers almost every kind of user interface, from a simple website all the way to a large SaaS service.

• Single-page apps (SPAs) — dynamic web applications that work without full page transitions. The web versions of Facebook, Twitter, and Instagram are canonical examples.
• Fullstack web apps — built as one set of Next.js + RSC + Server Actions + DB. You build one yourself in the Part 6 capstone of this book.
• Enterprise dashboards — complex admin screens where data changes in real time. The area where React’s component model shines brightest.
• Content sites and blogs — with a meta-framework like Next.js you can also build sites that index well in search engines.
• Mobile apps — with React Native you can build iOS and Android apps with the same mindset and similar code (outside the scope of this book).
• Desktop apps — combined with Electron, you can also build desktop applications for Windows, macOS, and Linux. VS Code, Slack, and Notion were all built this way (outside the scope of this book).

React, Vue, Svelte, Solid #

In 2026, React’s main competitors are Vue 3, Svelte 5, and Solid. Angular is still alive, but its share of new projects keeps shrinking.

• Vue 3 — a low entry barrier and friendly docs. The Composition API moved it closer to hooks in feel. Especially strong in the Chinese market.
• Svelte 5 — compile-time optimization keeps the runtime small. The runes model is similar in feel to React’s signals. The learning curve is short.
• Solid — an API almost identical to React’s, but with no virtual DOM and fine-grained reactivity. Gaining popularity in performance-sensitive projects.

React’s strength is “the largest ecosystem and the biggest hiring market.” Whatever problem you face, a tool already exists, and the vast majority of job postings call for React. Learning material is also the most abundant.

What this book covers #

This book is structured as 6 parts plus an appendix.

By the end of this book you will be able to:

• Build dynamic UIs with function components + hooks
• Type all of your code safely with TypeScript
• Build fullstack apps with Next.js App Router · Server Components · Server Actions
• Write component / integration / E2E tests with Vitest + Playwright
• Measure and improve Web Vitals
• Add auth with Auth.js, deploy to Vercel / Cloudflare Pages, and look into your production environment with Sentry + PostHog

Topics outside the scope of this book — React Native · Remix · TanStack Start, design systems · animation · WebGL — belong to separate books.

Exercises #

1. Skim the table of contents (Chapters 1 ~ 34 + Appendix A), and pick 1 ~ 2 chapters each that you feel you already know / that feel new to you / that you are most curious about. Keep the note around — you will use it to check your starting point after finishing the book.
2. Of the “five core traits of React” above, which one do you think React 19’s Server Components affect the most? Answer in one paragraph, and compare your answer with Chapters 22 ~ 24 after finishing the book.
3. Take one pass through Appendix A: Migrating Old React Code and mark any old styles you already know (class components · Pages Router · Redux-only · componentDidMount and so on). Whenever you hit one of those parts in the main text, cross-reference Appendix A — that becomes the starting point of your migration.

In one line: This book sets React 19, Next.js App Router, and TypeScript as the standard from page one. The four axes — function components + hooks · Server Components + Server Actions · TypeScript · one set of operations tools — run from Chapter 1 to Chapter 34 in the same voice. Old styles are gathered in Appendix A.

Next chapter #

In the next chapter, Chapter 2: Setting up the environment (Node.js + Vite), we install Node.js and pnpm, create our first React project with Vite, and spin up a dev server in order to start writing code in earnest. Every example in this book runs on top of that environment.