React and Next.js

Why it matters

The component model is now the default way most teams build UI

Breaking an interface into small, reusable pieces with their own state and props has become the standard approach across most frontend work, not just React specifically.

Rendering location affects real user-facing outcomes

A page rendered only in the browser can leave users staring at a blank screen while JavaScript loads, and search engine crawlers historically struggled with content that only appears after client-side rendering.

File-based routing removes a whole category of manual setup

A file's location in the project directly determines its URL, instead of a separate routing configuration file that has to be kept in sync by hand.

It lets a team keep light backend logic in the same project as the UI

API routes or server functions mean small backend tasks (form handling, a database call) don't always need a wholly separate service.

Components, props and state

function OrderStatus({ orderId }) {
  const [order, setOrder] = useState(null);

  useEffect(() => {
    fetch("/api/orders/" + orderId)
      .then((r) => r.json())
      .then(setOrder);
  }, [orderId]);

  if (!order) return <p>Loading...</p>;
  return <p>Status: {order.status}</p>;
}

What Next.js adds on top of React

Rendering: build time, request time, and in the browser

Mistakes people make here

Fetching data in useEffect when it could be fetched during rendering

A useEffect fetch only starts after the component has already rendered once, which typically means an extra loading state and a delay that server-side or render-time fetching can avoid entirely.

Mutating state directly instead of through its setter function

React doesn't detect a plain object or array mutation as a change and won't re-render, because it compares by reference — the fix is always creating a new value and passing it to the setter, not editing the existing one in place.

Making every component a client component out of habit in Next.js's app router

A component that doesn't need interactivity or browser-only APIs can usually stay a server component, sending no JavaScript for itself to the browser at all — defaulting everything to client-side ships more code than necessary.

Using an array index as a list item's key

React uses the key to track which item is which across re-renders; an index changes meaning when items are added, removed, or reordered, which can cause state to attach to the wrong item silently.

Strengths and trade-offs

Who needs this

Core to any frontend developer building beyond a static page; Next.js specifically matters once first-load speed, search visibility, or a combined frontend-and-light-backend project are real requirements.

Questions about react and next.js

Do I need Next.js to use React?

No — many React apps are built with just a bundler like Vite and a client-side router, with no framework layer on top. Next.js is a choice you make when its routing, rendering, and backend features solve problems you'd otherwise assemble yourself.

What does 'server component' mean in Next.js?

A component that renders on the server and sends no JavaScript of its own to the browser, as opposed to a client component, which does ship JavaScript and can use browser-only features like state and event handlers.

Is Next.js made by the same team as React?

No. React is maintained by Meta and the open-source community; Next.js is a separate framework, maintained by Vercel, built on top of React rather than being part of it.

Why would I choose Next.js over plain React?

When routing, server rendering, or an integrated backend layer would otherwise mean assembling and maintaining those pieces yourself — for a small app with none of those needs, plain React with a lightweight setup can be entirely sufficient.

The primary source

• React documentation ↗
• Next.js documentation ↗