React and Next.js are not the same thing. React provides UI components and the principles for updating them. Next.js bundles the common decisions needed to build and run a web application with multiple addresses using those components.
§ 00 · React is a library; Next.js is a framework
A library provides tools for a particular problem and leaves the developer to choose the rest of the application’s structure. React’s central problem is expressing UI with components and updating it as data changes.
A framework provides rules and a runtime for the application as a whole. Next.js uses React as its renderer and brings together file-based routing, layouts, server/client execution boundaries, data handling, and the basic structure needed for building and deployment. It is not a replacement for React, but a higher layer that includes and organizes React.
§ 01 · Decisions that remain after learning React
React alone can build browser UI. But the core React API does not prescribe one answer for defining multiple page URLs, generating the first screen on the server or in the browser, choosing where to read data, splitting code for delivery, or providing HTML to search engines and sharing cards.
Developers can assemble a router and build tools themselves or choose a framework that bundles these decisions. Next.js takes the latter approach. Learning React and learning Next.js therefore overlap, but are not identical. JSX and State are React’s language; conventions such as page, layout and route belong to Next.js.
§ 02 · What Next.js adds
Routing connects folders and special files to URLs and screens. Layouts define the shell shared by multiple pages. Rendering lets you create pages ahead of time, create them on the server when requested, and hand the necessary interactions over to the browser.
It also brings server-side data access, loading/error/404 UI, image and font optimization, code splitting, metadata and server endpoints into one system. You do not have to use every feature. The point is that the framework organizes potentially conflicting tool choices into one set of conventions.
| Layer | Main responsibility |
|---|---|
| React | Components, JSX, Props, State, Hooks and UI updates |
| Next.js | Routing, layouts, rendering strategies, server boundaries and the build system |
| Application | Domain rules, data models, user experience and operating policies |
§ 03 · View server and client as one component tree
In the Next.js App Router, pages and layouts are server-executed components by default. Server Components are useful for reading close to the data source, keeping secrets out of the browser and reducing the JavaScript sent to it.
Client Components handle parts requiring State, event handlers, useEffect or browser APIs. “use client” marks a file as a boundary of the browser-side module graph. Server and Client Components are not competitors; they divide static and interactive work within one tree.
§ 04 · A useful combination, but not the only one
For a website needing multiple URLs, server data, search visibility, sharing metadata, static generation and server rendering, React with Next.js settles many decisions at once. The advantage is gaining a structure for the whole application while retaining React’s component model.
For a small widget, a learning screen or a simple browser-only tool, you can instead use React alone or choose other build tools and frameworks. Using Next.js does not automatically produce a good app. A framework does not eliminate decisions; it reduces recurring ones through defaults and conventions.
Read this note at sass.studio.