What is React?

React is a JavaScript library for building user interfaces. It was created at Facebook by Jordan Walke and first open-sourced in 2013. Today it is maintained by Meta, developed openly on GitHub under the MIT license, and is the foundation under most large frontend applications shipped today - Facebook itself, Instagram, WhatsApp Web, Netflix, Airbnb, Stripe, Shopify, and the long tail of products built on top of Next.js and Remix.

The word library is doing real work in that description. React focuses on one job: turning component code into a rendered, interactive UI. It does not ship a router, a state-management solution, a data-fetching layer, or a build tool. Those decisions are intentionally left to the application and its ecosystem - which is the source of both React's power and its sharpest edges.

The library for web and native user interfaces.- react.dev

Why teams choose React

React has been the default choice for new frontend projects for nearly a decade. The reasons compound:

  • A component model that scales. UI is built from small, composable functions that take inputs and return rendered output. Components are the unit of reuse, of testing, and of mental load.
  • JSX puts markup next to logic. Templates and the code that drives them live in the same file. Refactors that change both are local edits, not coordinated changes across template-engine boundaries.
  • An enormous ecosystem. Routing, forms, data fetching, state management, animation, charts, design systems - if you can name a frontend problem, there is a mature React library that solves it. Most major libraries publish first-party TypeScript types.
  • The hiring market. React is the most common skill on frontend resumes by a wide margin. Onboarding a new engineer to a React codebase is a known quantity.
  • Frameworks built on top. Next.js, Remix, and Astro provide the routing, server-rendering, and bundling that React itself does not - turning React into a complete application platform when paired with one of them.

The trade-off is the same one in every direction: React asks you to assemble your stack. The freedom is real, and so is the responsibility.

Components and JSX

A React component is, in modern code, just a JavaScript function that returns markup. The markup is written in JSX - a syntax extension that looks like HTML but compiles down to plain JavaScript function calls.

TSX Greeting.tsx
type Props = { name: string }; export function Greeting({ name }: Props) { return <h1 className="display">Hello, {name}</h1>; }

That is the entire contract. The component takes props (inputs), returns markup (output), and React renders the result. No class hierarchy, no lifecycle methods, no framework-specific decorators. Components compose by calling each other:

TSX App.tsx
export function App() { return ( <main> <Greeting name="Anders" /> <Greeting name="Evan" /> </main> ); }

JSX is not HTML. class becomes className (because class is a reserved word in JavaScript), for becomes htmlFor, attribute values use JavaScript expressions inside {} braces, and every element you use either resolves to a real DOM tag (h1) or to a component you imported (Greeting). The compiler that turns JSX into JavaScript is usually esbuild or SWC - both are fast enough that the transform is invisible during development.

State, props, and the data flow

React's data flow is intentionally one-directional. Data flows down through props - a parent component passes values to its children. Events flow up through callbacks - children call functions the parent gave them, and the parent decides what to do.

Component-local state lives inside the component, declared with the useState hook:

TSX Counter.tsx
import { useState } from "react"; export function Counter() { const [count, setCount] = useState(0); return ( <button onClick={() => setCount(count + 1)}> Clicked {count} times </button> ); }

When state changes, React re-runs the component function with the new value and updates the DOM to match the new returned markup. The developer describes what the UI should look like for any given state; React handles the how of making it true.

For state that needs to be shared across components, lift it up to the closest common ancestor or reach for a state-management library (Zustand, Jotai, Redux Toolkit) or a server-state library (TanStack Query, SWR). The default React API does not pick for you.

Hooks - the modern API

Hooks were introduced in React 16.8 in 2019 and have been the standard way to write React ever since. A hook is a function whose name starts with use, called at the top of a component, that lets the component participate in React's render machinery. The five most-used hooks cover the bulk of real code:

useState
Component-local reactive state.
useEffect
Side effects after render - subscriptions, manual DOM work, integration with non-React code.
useMemo
Memoize an expensive computation across renders.
useCallback
Memoize a function identity so child components don't re-render unnecessarily.
useContext
Read a value provided by an ancestor through a Context.

Custom hooks - functions you write that compose other hooks - are how reusable behavior moves between components. A useDebounce, useLocalStorage, or useOrders hook reads like a normal function call inside any component that needs it:

TSX SearchBox.tsx
export function SearchBox() { const [query, setQuery] = useState(""); const debounced = useDebounce(query, 300); const { data, isLoading } = useOrders(debounced); return ( <div> <input value={query} onChange={e => setQuery(e.target.value)} /> {isLoading ? <Spinner /> : <OrdersList orders={data} />} </div> ); }

The discipline that makes hooks work is simple: call them at the top of the component, in the same order every render, never inside conditions or loops. The compiler will tell you when you slip - and modern React projects ship with an ESLint rule that enforces this.

The ecosystem (and why React is not a framework)

This is the most-asked question about React: is it a framework, or just a view library? The honest answer is just a view library. React itself ships rendering, components, hooks, and a small set of context APIs. Everything else lives outside the core.

The ecosystem fills the gap. The pieces a typical React application reaches for:

  • Build tool. Vite for most new projects. It scaffolds React + TypeScript in one command.
  • Type system. TypeScript is the default - the official Vite template is TSX, and most teams write TSX from day one.
  • Routing. React Router for client-side navigation, or a meta-framework that handles routing for you.
  • Server state. TanStack Query, SWR, or a data layer baked into a framework.
  • Client state. The built-in useState + useReducer for most cases. Zustand, Jotai, or Redux Toolkit when state has to be shared globally.
  • Meta-frameworks. When you want React with batteries included, you reach for one: Next.js (SSR, file-based routing, server components), Remix (data loaders, nested routes), Astro (multi-framework, content-focused), or TanStack Start. These are not "React alternatives" - they are React, with a framework built around it.

The library-vs-framework distinction matters in practice because it sets your expectations. If you compare React directly to Angular, you are comparing different categories of tool. Angular ships routing, forms, HTTP, DI, and CLI in the box. React ships a renderer. Pairing React with a meta-framework like Next.js gets you closer to Angular's surface area - and the comparison becomes more even.

When to reach for React

Reach for React when you want a flexible foundation, a deep ecosystem, and a hiring pool that already knows the API. Pair it with a meta-framework if you want batteries included; pair it with Vite + React Router if you want to assemble the stack yourself.

Reach for something else when you want a full framework out of the box (Angular), when you want to ship the absolute smallest bundle (Preact, Svelte), or when the application is genuinely a marketing site rather than an interactive UI (in which case Astro or a static-site generator is probably the right call).

For most everything in between, React is the default - and the default it is because the alternatives that beat it are good alternatives, not because React itself stopped improving.

References