Someone has told you your new site should be built in React. Someone else has said Next.js. People trade the names as if they were rival products, which makes the choice sound like a matter of taste. It isn’t.
What each one actually is
React is a library for building user interfaces. Developers use it to describe what a screen should look like, and it keeps the screen in step with the data behind it. It doesn’t decide how visitors move between pages, or whether a page is assembled in the browser or on the server.
Next.js is a framework built on top of React. It keeps React’s way of building interfaces and adds what React leaves out: routing, a choice of rendering strategies, and server-side capability. So you aren’t choosing between two rivals. You’re deciding whether you need that extra layer.
The question that actually decides it
A plain React application is usually a single-page application. The browser downloads a bundle of JavaScript, runs it, and builds the page. The first person to arrive waits for all of that before they see anything meaningful. After that every screen is quick, because the application is already running.
That’s fine when the people using the screen are already committed: they’ve signed in, and nobody found the page through a search engine. It’s a poor trade for a stranger who arrives from a search result on a phone and will judge the site in a second or two.
Next.js changes where the work happens. Server-side rendering assembles the page on the server, so it arrives as finished HTML. Static generation builds it ahead of time, and incremental regeneration refreshes those files as the content changes. React still takes over in the browser afterwards (that handover is called hydration), but the visitor and the crawler both get real content straight away.
When plain React is the right call
An internal dashboard is the clearest case. Nobody searches for it, and every user signs in first. The first load happens once at the start of the day, and after that it’s interactions, not page loads. Server rendering would add machinery that nobody there benefits from.
The same goes for software behind a login, such as a customer portal, an admin area or an operations tool. Search visibility doesn’t matter there, client-side rendering keeps the architecture small, and the workflow itself is what counts. That’s the work our custom web application development service is built for.
React on its own also suits interactivity added to a page that already exists, like a booking widget or a configurator inside a site built on something else. There you want a component, not a framework taking over the routing.
When Next.js earns its place
Marketing pages, product pages, documentation and a blog are the opposite case. They exist to be found. A crawler has to read them, and a first-time visitor has to see something useful before their patience runs out. Server rendering and static generation are built for exactly that.
E-commerce is the most demanding version. A product page has to be findable, appear quickly on a modest connection, and stay accurate while stock and prices change. Static generation with incremental regeneration serves a catalogue as pre-built pages and refreshes them as the data changes.
This is also where the Core Web Vitals come in. LCP is how long your main content takes to appear, INP is how quickly the page responds, and CLS is whether the layout stays still. No framework wins them on its own. Where each page is rendered is where our React and Next.js development work starts, route by route.
When the answer is neither
Sometimes the right answer is neither of them. If what you need is a brochure site, with a few pages about the business, a blog your team edits and a contact form, React and Next.js won’t do you any favours. A framework puts a developer between your team and every word on the page.
You’re probably in that position if:
- The site is mostly text and images, and it changes weekly rather than by the second.
- Your team needs to publish and edit without asking a developer first.
- Nothing on the page depends on live data or on who’s logged in.
When all three are true, a content management system will serve you better. Your team works in an editor they recognise, pages are server-rendered by default, and the site can still be optimised for speed. That’s what our WordPress development and modernization service is for, and we say so when it’s the answer.
The framework follows the problem
None of this came down to popularity, or to what a previous developer preferred. Each answer came from the shape of the problem: who looks at the page, whether a search engine reads it, and who edits the words.
We work in the same order. You describe the goal. We ask about your users, your business goal and your constraints, then recommend a scope and approach, including whether the technology you came to us with fits. Then we build and share progress for feedback before launch, with ongoing development and maintenance available afterwards.
If you’ve been handed one of these names and can’t tell whether it fits what you’re building, describe the project and get in touch. We’ll tell you which of the three answers applies, including the one where you need no framework at all.