What is React

A JavaScript library for building user interfaces out of reusable components - what React actually is, why it exists, and how it fits with plain JavaScript.

What it is, in plain English: React is a JavaScript library (not a framework) for building user interfaces. Its core idea: describe what the UI should look like for any given state, and React figures out the minimal DOM changes needed to make that true. You build interfaces by composing small, reusable pieces called components. React was created by Facebook (now Meta) in 2013 and is maintained by Meta alongside a large open-source community.

A different way to think about building UIs

Without React, building an interactive page means manually finding DOM elements and updating them every time something changes — easy to forget a spot, easy to create bugs where the screen doesn't match the actual data.

React flips this: you write a function that describes what the UI should look like for the current data. Whenever that data changes, you call the function again, and React automatically figures out the minimum changes needed to update the real page.

The simplest React component

function Welcome() {
  return <h1>Hello, World!</h1>;
}

// This looks like HTML inside JavaScript — that's JSX (covered in the next page).
// A "component" is just a JavaScript function that returns what should appear on screen.

Why React exists

// The problem React solves: keeping the UI in sync with data, as an app grows.

// Small apps: manual DOM updates are manageable.
// Real apps: dozens of pieces of data, all affecting different parts of the screen.
// Manually tracking "when X changes, update Y, Z, and W" becomes unmanageable.

// React's answer: don't track individual updates.
// Just describe the WHOLE UI based on the CURRENT data, every time.
// React's diffing algorithm only touches what actually changed.

Components — the core building block

// A React app is a tree of components, each one a small, focused piece of UI:
function App() {
  return (
    <div>
      <Header />
      <ProductList />
      <Footer />
    </div>
  );
}

function Header() {
  return <header><h1>My Store</h1></header>;
}

// Each component manages its own piece of the UI.
// Components can be reused anywhere — write once, use everywhere.

What React is NOT

// React is a LIBRARY, not a full framework.
// Out of the box, React only handles UI rendering.

// You add separate libraries for:
// - Routing      → React Router, or built into Next.js
// - Data fetching → fetch/axios + TanStack Query, or built into Next.js
// - State (global) → Context API, Zustand, Redux
// - Styling       → CSS, Tailwind, styled-components

// "Frameworks" like Next.js bundle React + routing + data fetching + more
// into one opinionated package. React itself stays small and focused.

Try It Yourself (JSX)

// React's core idea: describe WHAT the UI should look like, not HOW to update it

// Without React (imperative -- you manage every DOM change):
// let count = 0;
// const button = document.querySelector("button");
// const display = document.querySelector("#count");
// button.addEventListener("click", () => {
//   count++;
//   display.textContent = count;   // YOU must remember to update this
// });

// With React (declarative -- describe the result, React handles updates):
function Counter() {
  const [count, setCount] = React.useState(0);

return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>
    </div>
  );
}

// This is the entire mental model of React:
// 1. State changes (setCount called)
// 2. Component function re-runs, returns new JSX
// 3. React compares new JSX to what's on screen
// 4. React updates ONLY the parts of the DOM that actually changed

console.log("React renders declaratively -- describe the UI, not the updates");

function App() {
  return <Counter />;
}

The virtual DOM and React's rendering model

The virtual DOM, conceptually

// React keeps a lightweight JS representation of the UI (the "virtual DOM").
// When state changes:
// 1. React calls your component function again → gets a NEW virtual DOM tree
// 2. React compares (diffs) the new tree against the previous one
// 3. React calculates the minimal set of real DOM operations needed
// 4. React applies only those changes to the actual browser DOM

// This is why you NEVER manually touch the DOM in React code:
// document.querySelector(...).textContent = ...   ← never do this in React
// Instead: update state, let React handle the DOM:
setCount(count + 1);  // React re-renders and updates the DOM for you

Why "re-render" doesn't mean "redraw everything"

// A common misconception: "re-render" sounds expensive, like repainting the whole page.
// In reality: re-running your component function is cheap (it's just JS).
// The EXPENSIVE part — touching the real DOM — only happens for what actually changed.

function App() {
  const [count, setCount] = React.useState(0);
  return (
    <div>
      <ExpensiveStaticComponent />   {/* re-renders too, but its OUTPUT is identical */}
      <p>{count}</p>                  {/* only THIS text node actually updates in the DOM */}
      <button onClick={() => setCount(c => c + 1)}>+1</button>
    </div>
  );
}

React 18+ vs older versions

// React 18 introduced concurrent rendering — React can pause, interrupt,
// and resume rendering work, prioritising urgent updates (like typing)
// over less urgent ones (like a large list re-rendering).

// The new root API (React 18+):
import { createRoot } from "react-dom/client";
const root = createRoot(document.getElementById("root"));
root.render(<App />);

// Old API (React 17 and earlier — still works but deprecated):
// ReactDOM.render(<App />, document.getElementById("root"));

Fiber architecture and React's reconciliation algorithm

// React's reconciler (called "Fiber" since React 16) is a linked-list-based
// data structure representing the component tree, enabling React to:
// - Pause work and come back to it later
// - Assign different priority levels to different updates
// - Reuse previously completed work
// - Abort work if it's no longer needed

// Reconciliation algorithm (simplified):
// 1. Same component type at same position → update props, keep DOM node, recurse into children
// 2. Different component type at same position → unmount old, mount new (full subtree replaced)
// 3. Lists: React uses the `key` prop to match elements across renders
//    Without keys, React falls back to index-based matching (can cause bugs with reordering)

// Why keys matter:
const items = list.map(item =>
  <li key={item.id}>{item.text}</li>   // ✓ stable identity across re-renders
  // <li key={index}>{item.text}</li>  // ✗ breaks if list is reordered/filtered
);

React's rendering phases

React 18's concurrent renderer splits work into two phases: the render phase (calling component functions, building the new Fiber tree — interruptible, can be thrown away) and the commit phase (applying changes to the real DOM — synchronous, never interrupted, because partial DOM updates would be visible to the user). This split is why React component functions must be pure — React may call them multiple times, or abandon a render entirely, before committing.

Official Sources

The Codex links only to official documentation. No third-party tutorials.