React or Next.js: what to choose for a new product
React builds user interfaces, and Next.js is a framework built on React that adds routing, rendering and server features. Here is how to choose for a new product.
React is a library for building user interfaces. Next.js is a framework built on top of React that adds routing, server rendering, data loading and a build pipeline. For most new products that need search visibility, a public marketing site or a mix of public and signed-in pages, Next.js is the sensible default. Plain React with a bundler is enough when the product is a signed-in app that search engines never need to see.
Library versus framework
The difference is how much decision-making is done for you.
| Aspect | React with a bundler | Next.js |
|---|---|---|
| Routing | You pick a library and define routes in code | Files and folders become routes |
| Rendering | Client-side by default | Client, server or static, per page |
| Data loading | Usually in the browser after load | Can load on the server before sending |
| Build and assets | You assemble the pieces | Production build, image and font handling included |
| Where it runs | Any static host | Needs somewhere to run server code, unless exported static |
You still write React components either way. With Next.js you are choosing a structure around them.
Rendering: client, server, static
Rendering is the biggest practical difference. These three terms stay stable even as framework features change.
| Mode | What happens | Best for | Cost |
|---|---|---|---|
| Client-side | Browser downloads a shell and JavaScript, then builds the page | Screens behind a login | First view waits for JavaScript |
| Server-side | Server builds complete HTML for each request | Content that changes per request or user | Server work on each visit |
| Static | Pages built ahead of time, served as files | Marketing pages, documentation | Needs a rebuild to change |
Next.js lets you mix these per page, or even per part of a page. A pricing page can be static, a dashboard can be client rendered, and a product listing can be rendered on the server. Plain React with a bundler gives you client rendering out of the box, and the other two need extra work or a framework.
Routing and data fetching
In a plain React app you pick a routing library and usually fetch data in the browser after the page loads. That means loading states and, if one fetch depends on another, a request waterfall.
Next.js lets a page load its data on the server before it is sent. The user gets content in the first response, and you can keep sensitive logic and credentials on the server, where the browser never sees them. Nested layouts avoid reloading shared chrome like navigation when users move between pages.
Next.js can also host server-side endpoints next to the pages, which suits light backend work. For a larger backend, teams often keep a separate service in Node.js or another runtime, with Next.js as the front end that calls it.
SEO and performance
If search traffic matters, send complete HTML. Search engines can run JavaScript, but pages that render on the server or ahead of time are easier to crawl and index, and they usually show content sooner for real users. Social link previews and AI answer tools also read the initial HTML more reliably than they run your scripts.
Performance is about what you send and when. Next.js helps with code splitting per route, image optimization and font loading. These support the user-centered measures grouped as Core Web Vitals, which cover loading, responsiveness and visual stability.
Hosting
A static or client-rendered React build is just files, so any static host or content delivery network can serve it cheaply.
Next.js apps that use server rendering or server endpoints need somewhere to run server code: a platform built for the framework, a container on a cloud provider or your own servers. Decide early where it will run and who owns it. A fully static Next.js export returns you to simple file hosting, without server features.
How to decide
Follow this order:
- Do public pages need to rank in search or preview well when shared? If yes, lean Next.js.
- Does the product mix public content with signed-in features? If yes, lean Next.js.
- Is it a signed-in tool, admin dashboard or embedded widget? If yes, plain React is enough.
- Can you say in one sentence why you need server rendering? If not, start simple.
| Choose React with a bundler such as Vite when | Choose Next.js when |
|---|---|
| The product lives behind a login, like an internal tool | Public pages must rank or preview well when shared |
| You already have a separate API and want a thin client | The product mixes public content with signed-in features |
| Your team wants full control and can assemble the pieces | You want one codebase and deployment for pages and light server logic |
| You are embedding a widget in an existing page | You would rather follow a well-trodden structure |
Before you commit, check:
- You know which pages must be visible to search engines
- You know where server code will run, and who owns it
- You have a plan for the backend: light endpoints or a separate service
- The team has built in the framework you chose before, or has time to learn it
- TypeScript is on from the first commit
TypeScript
Whichever you pick, use TypeScript. Typed props and API responses catch a whole class of mistakes before they reach users and make refactoring safer. Adopting it at the start costs little compared with retrofitting it later.
How this looks at Techdome
Our web and app development work centers on React, Next.js and Node.js, and we place React, Node.js and full-stack developers in dedicated engineering pods. This website, techdome.io, is itself built with Next.js and React. The executive-health clinic group's operating system is built with Next.js and TypeScript as an offline-first progressive web app (An Executive-Health Clinic Group), and the multi-vendor care ecosystem's single sign-on work pairs Next.js with Node.js (A Multi-Vendor Telehealth Care Ecosystem).
The telehealth platform for the GLP-1 space lists React and Node.js in its stack (A US & UK Telehealth Platform).
Takeaways
- React is a UI library, and Next.js is a framework that adds routing, rendering and server features on top.
- Pick Next.js when you need public pages to be crawlable and fast, or when you mix public and signed-in features.
- Pick React with a bundler for signed-in apps and tools where search visibility does not matter.
- Match the rendering mode to the page: static for stable content, server for per-request content, client for interactive app screens.
- Use TypeScript from the first commit, whichever you choose.
Have a project like this? Talk to our engineers.
