What is React? A developer's guide to building web applications

React is a JavaScript library for building user interfaces. In practice, developers use it to build web apps from small reusable pieces called components. Each component describes what part of the screen should look like, React keeps that view in sync with data, and the browser shows the result.

In simple terms:

• React helps you build interactive screens.
• Components are the basic building blocks.
• JSX lets you write HTML-like markup inside JavaScript.
• State is the data that changes as people use the app.
• Hooks are functions that let components use React features.
• React is not a complete web framework by itself. You still choose routing, data fetching, styling, testing, hosting, and often a framework.

The plain-English version

React is a way to organise a web interface so it does not turn into a pile of tangled HTML, CSS and JavaScript.

Instead of manually finding DOM nodes and changing them one by one, you describe the screen for a given state. If the state changes, React works out what needs to change in the browser.

That is the bit that makes React click.

state changes -> React renders components -> browser updates the UI

A counter is the smallest useful example:

import { useState } from 'react';

export default function Counter() {

  const [count, setCount] = useState(0);

  return (

    <button onClick={() => setCount(count + 1)}>

      Clicked {count} times

    </button>

  );

}

There is not much code there, but it shows the core idea. The component has state, the user clicks, the state changes, and React updates the button text.

Why developers use React

Developers reach for React because modern web applications are full of repeated interactive pieces: navigation menus, buttons, forms, modals, filters, dashboards, cards, tabs, settings pages and checkout flows.

React gives those pieces a consistent shape.

React is popular because the component model maps neatly to how product teams think. A design system has buttons, cards and forms. A React codebase can have the same things as components.

React is a library, not the whole application

This matters more than beginners expect.

React handles the view layer. It helps you build the UI. It does not, by itself, make every decision a production web app needs.

That is not a weakness. It is the tradeoff. React gives you a strong UI model and leaves room to choose the rest of the stack.

The building blocks of React

Most React learning paths are less mysterious when you see the pieces together.

If you understand those, you understand the everyday shape of React work.

Components are the centre of React

A component is a piece of UI with its own logic and appearance. It can be tiny, like a button, or large, like a whole page.

function ProductCard({ name, price }) {

  return (

    <article className="product-card">

      <h2>{name}</h2>

      <p>${price}</p>

      <button>Add to cart</button>

    </article>

  );

}

Then you can use it like this:

<ProductCard name="Keyboard" price="149" />

<ProductCard name="Mouse" price="79" />

The practical benefit is reuse. You design the card once, make it flexible with props, then render it wherever you need it.

A good React app usually feels like a tree of components, not a long script that pokes at the page.

JSX is JavaScript with markup in it

JSX is the syntax most React developers use to describe UI. It looks like HTML, but it is stricter and it lives inside JavaScript.

const user = { name: 'Ada', role: 'Developer' };

function Profile() {

  return (

    <section className="profile">

      <h2>{user.name}</h2>

      <p>{user.role}</p>

    </section>

  );

}

The curly braces switch back into JavaScript. That lets you display variables, call functions, build class names, render lists and choose what appears on the screen.

JSX has a few rules that trip people up early.

JSX is not required, but most React teams use it because the UI structure is easy to read at a glance.

Props, state and events

These three concepts do a lot of work.

Props are inputs. State is memory. Events are what happen when users interact.

Here is a simple form field:

import { useState } from 'react';

function NameField() {

  const [name, setName] = useState('');

  return (

    <label>

      Name

      <input

        value={name}

        onChange={(event) => setName(event.target.value)}

      />

      <p>Hello, {name || 'stranger'}.</p>

    </label>

  );

}

The input value comes from state. The onChange event updates that state. React renders the greeting from the latest value.

That pattern appears everywhere in React apps.

The mental model: describe the result, not every DOM step

Old-school DOM scripting often looks like this:

Find the element.

Change its text.

Add a class.

Remove another class.

Disable a button.

Show a message.

React pushes you towards a different approach:

What state is the app in?

What should the UI look like for that state?

A login form might have states like this.

This makes UI bugs easier to reason about because the screen follows the data.

Hooks without the mystery

Hooks are special functions that let React components use React features. They are just functions, but they follow React's rules.

The hooks beginners see first are these.

The most common beginner mistake is reaching for useEffect too quickly. If you can calculate something from props or state during render, do that instead.

function InvoiceTotal({ items }) {

  const total = items.reduce((sum, item) => sum + item.price, 0);

  return <p>Total: ${total}</p>;

}

You do not need an effect for that. The value is derived from existing data.

How React turns components into a web page

A React app has three broad phases when something changes.

React does not blindly redraw the whole page in the way people sometimes imagine. It works out what changed and updates the DOM accordingly.

As a developer, you usually focus on writing pure components: given the same props and state, the component should return the same UI.

How to start a React app

For a simple client-side React app, Vite is a common starting point.

npm create vite@latest my-react-app -- --template react-ts

cd my-react-app

npm install

npm run dev

That gives you a local development server and a modern build setup. For production, you usually run:

npm run build

npm run preview

A typical small React project might look like this:

my-react-app/

  src/

    App.tsx

    main.tsx

    components/

      Button.tsx

      ProductCard.tsx

    pages/

      HomePage.tsx

    styles/

      global.css

  package.json

  vite.config.ts

The exact structure is not sacred. React gives you flexibility, which is useful once you know what you are doing and a little dangerous when you do not.

What React does not decide for you

React's flexibility means you must make some architecture choices.

A small dashboard can be fine with React, Vite and a router. A content-heavy public site probably wants server rendering or static generation. A complex SaaS product needs stronger conventions around data, permissions, forms and testing.

React and frameworks like Next.js

React is the UI library. A framework adds app-level decisions around routing, rendering, data loading, file structure and deployment.

My usual advice: learn React fundamentals first, then learn a framework. If you skip the fundamentals, the framework feels like magic. If you only learn bare React, production apps can feel under-specified.

How developers use React to build real web applications

A real React app is not just a pile of components. It is a set of decisions that fit together.

That order keeps you honest. If the static UI is messy, adding state will not fix it. If the data model is messy, adding a state library will not fix it either.

Common React application patterns

The important habit is to model the UI state deliberately. Do not scatter copies of the same data across half a dozen components unless there is a very good reason.

React compared with nearby options

React is not the only way to build web interfaces. The right comparison depends on what you are building.

React is a good default when you want a broad ecosystem and a component model that many developers already know. It is less appealing if you want one official answer for every architectural decision.

React 19, Actions and Server Components

React 19 matters because it continues shifting React beyond purely client-side UI code.

The headline features for everyday developers are around async workflows and forms. Actions let React handle common mutation states such as pending, errors and optimistic updates more directly. Hooks like useActionState and useOptimistic support those patterns.

Server Components are the bigger architectural idea. A Server Component can render ahead of time, at build time or per request, in an environment separate from the client app. That can keep server-only work and heavy libraries out of the browser bundle.

If you are new to React, do not start with Server Components. Start with components, props, state and hooks. Then learn how your chosen framework uses the server.

Best practices that save pain later

React codebases usually go wrong in predictable ways. The fixes are not glamorous, but they work.

A clean React app is usually boring in the best way. Data flows down, events flow up, and state lives in the smallest sensible place.

Mistakes I see developers make with React

The pattern behind most mistakes is the same: using a tool before the problem asks for it.

A practical React learning path

If you are learning React now, I would not start by memorising every API. Learn the working set first.

A good first serious project is a small dashboard with authentication mocked out, a few routes, real forms, filters, API data and tests for the most important paths. That teaches more than another isolated counter tutorial.

FAQ about React

Is React hard to learn?

React is approachable if you already know JavaScript, HTML and CSS. The hard part is not the component syntax. The hard part is learning state, data flow, effects, tooling and the wider ecosystem.

Do I need TypeScript with React?

No, but I would use it for most serious projects. TypeScript makes component props, API responses and shared types much safer as the app grows.

Can React build a whole website?

Yes, but React alone is only the UI layer. For a full website or application, you also need decisions about routing, data loading, rendering, styling, testing and deployment. A React framework can handle many of those decisions.

Is React good for SEO?

React can be good for SEO when rendered appropriately. A purely client-rendered app can be weaker for public content if it delays meaningful HTML. For SEO-heavy sites, use server rendering, static generation or a framework that outputs crawlable pages.

Should I learn React before Next.js?

Yes. You do not need to master all of React first, but you should understand components, props, state, events, hooks and rendering before going deep into Next.js. Otherwise you end up debugging both React and the framework at once.

What is the difference between React and React Native?

React is the UI model. ReactDOM renders React components to the web DOM. React Native uses React ideas to build native mobile interfaces. The concepts overlap, but the rendered elements and platform APIs differ.

Does React replace HTML and CSS?

No. React uses HTML-like JSX and still relies on CSS or styling tools. Good React developers still need strong HTML, CSS, accessibility and browser fundamentals.

When should I not use React?

Do not reach for React by reflex. A simple marketing page, small static site or server-rendered form might be easier without a full React app. React earns its keep when the interface is interactive, component-heavy or likely to grow.

The bottom line

React is a component model for building user interfaces with JavaScript. Its power is not that it makes every web problem disappear. It gives developers a clear way to build interactive screens from reusable pieces and keep those screens in sync with changing data.

For a developer, the sensible path is simple: learn components, JSX, props, state and hooks. Build a few real interfaces. Then decide whether your app needs a simple Vite setup or a fuller React framework.

React is best when you treat it as the UI layer in a deliberate application stack, not as a magic answer to the whole web.