Getting Started With React

There is a version of learning React that starts with npm create vite@latest, generates a folder of thirty config files, and hands you a blinking cursor. You are running React. You have no idea what is happening. Everything works until something breaks, and when it breaks, you have no idea where to look.

That is not how this series works.

The First Principles Approach

The philosophy behind this course is simple: if you add tools before you understand the problem they solve, you will resent those tools. They feel like arbitrary complexity with no upside. But if you first hit the problem yourself -- actually feel the friction of writing raw React.createElement calls by hand -- then when a tool arrives to handle it, you understand exactly what it bought you. You appreciate it.

So we start with nothing. Literally a single HTML file with two <script> tags pointing at the React CDN. No bundler, no JSX transformer, no npm. Just a browser.

Then we hit friction. And then we add tools, one at a time, with a reason for each one.

By the time Vite and JSX show up a few posts in, you are not just trusting that they are doing something useful. You know exactly what they are abstracting, because you have done it the hard way first.

What We Are Building

The project is a pizzeria called Padre Gino's. (Padre is Spanish, not Italian. It was on the design mockup and it was too charming to change.)

By the end of this series, the app has:

• A pizza of the day, fetched from an API
• An order form with pizza type, size, and a cart
• A past orders page with per-order modal detail
• A contact form
• Full client-side routing between pages
• A working test suite, including browser tests with Playwright

ExpandComplete Intro to React v9 Tech Stack

The tech stack is what you would actually choose starting a new React project today: Vite for bundling, TanStack Router for routing, TanStack Query for data fetching, and Vitest for tests.

This Course Is Client-Side React

A quick clarification that will save confusion later: this entire course is client-side React. No React Server Components, no server actions run on Node, no Next.js. All of that is genuinely useful technology, but it is not what this course is about.

There is a narrative that client-side React is no longer the right choice and that every project should be using a meta-framework. I do not think that is accurate for most of what gets built. The majority of apps do not have the scaling pressures that motivated server components. A well-structured client-side React app is fast, maintainable, and completely reasonable to ship.

This matters for how you read the series. When you see useEffect for data fetching, I am not going to stop and say "but in production you would use a server component." We will use TanStack Query instead -- which is the right client-side answer -- and leave the server-side story for a different time.

Prerequisites

This is not the right starting point if you have never written JavaScript. You should be comfortable with functions, objects, arrays, and asynchronous code before any React makes sense. The JavaScript foundations series on this blog covers that ground if you need it.

No Node.js knowledge is required. We will use Node as part of the build process, but we will not be writing any Node code directly.

Setup

Check your Node version:

You need Node 20.6 or higher. If you need to upgrade, use nvm or download directly from nodejs.org.

Clone the course project repo, which contains snapshots of the completed codebase at each major step:

The repo has seventeen numbered folders. Each one is a complete checkpoint. If your code goes sideways halfway through a chapter, you can open the matching folder, run npm install, run npm run dev, and have working code immediately to compare against or continue from.

The API server also lives in this repo, so cloning it is not optional -- we will need it as soon as data fetching enters the picture.

What Is React Actually Solving

Before any code, it is worth naming the problem.

A browser UI is mutable state rendered as DOM nodes. When data changes -- a cart updates, a form value changes, an API responds -- something has to decide which DOM nodes to touch and how. That "something" is where complexity hides.

The naive approach is full re-renders: rebuild the whole UI from scratch on every change. Correct, but slow for anything complex. React's solution is to build a lightweight description of the UI in memory -- the virtual DOM -- compare it to the previous description, and only update the real DOM nodes that changed. That diffing step is called reconciliation.

You never call it directly. You write components that return a description of what the UI should look like given the current state, and React figures out the minimal set of DOM changes needed to get there. That is the core trade: give up direct DOM control, get predictable rendering.

The next post starts with exactly this -- loading React from a CDN and writing a component with nothing but React.createElement. By components and props you will be building the Pizza menu cards that drive the whole app.

The Essentials

1. First principles over fast setup. Start with no tools to understand what each tool solves. Tools feel like complexity until you have hit the problem they fix.
2. Client-side React is the whole course. No server components, no meta-framework. Client-side React is a completely viable choice for most apps.
3. The virtual DOM trade. React manages DOM updates by comparing virtual descriptions of the UI. You write what the UI should look like; React decides what to change.
4. What we are building. Padre Gino's pizzeria -- order form, cart, past orders, contact form, routing, and tests.
5. Node 20.6+. Clone the course project repo; it has seventeen checkpoint folders and the API server.
6. JavaScript confidence required. Functions, objects, arrays, async. No Node.js experience needed.

Further Reading and Watching

• React in 100 Seconds -- a sharp, visual answer to "what is React and why does it exist"
• Thinking in React -- the official mental model for decomposing a UI into components and deciding where state lives