React vs Next.js: which should businesses choose?

The framing is wrong from the start. React is a library for building interfaces. Next.js is a framework built *on* React that adds routing, server rendering and build configuration. Choosing "React over Next.js" means choosing to assemble those pieces yourself.

So the real question is narrower: does your product need server rendering?

What server rendering actually changes

Without it, the browser downloads an almost-empty HTML file plus a JavaScript bundle, runs the bundle, fetches data, and only then paints something. With it, the server sends complete HTML that paints immediately, and JavaScript takes over afterwards.

Two consequences follow, and both are commercial rather than technical.

Search engines

Search crawlers can execute JavaScript, but rendering is queued separately and given a budget. Pages that return complete HTML get indexed reliably and quickly. Client-rendered pages get indexed less predictably and compete poorly for the same queries.

If organic search matters to your business, this is not a preference. It is close to a requirement.

First-load performance on real devices

On a fast laptop the difference is small. On a mid-range Android phone over mobile data — which is a large share of real traffic — parsing and executing a large bundle before anything appears is very noticeable.

When plain React is the right answer

Server rendering has a cost: server infrastructure, more complex caching, and a mental model where code runs in two places. That cost is not always worth paying.

Choose plain React when:

• The entire product sits behind a login, so SEO is irrelevant
• It is an internal tool where users are already committed and waiting a moment is fine
• You are adding interactivity to part of an existing site rather than building a whole application
• Your team wants explicit control over routing and build configuration

A dashboard used by staff all day has no SEO value and benefits little from server rendering. Reaching for Next.js there adds complexity for no return.

When Next.js is the right answer

• Any part of the product needs to be found in search
• First-load performance affects conversion — commerce, marketing, sign-up flows
• You have both a public marketing surface and an authenticated product, and want them in one codebase
• You want image optimisation, routing and bundling handled rather than assembled

The comparison that matters

The mistake we see most

Teams pick Next.js for the right reasons, then mark a top-level layout as a client component because one button inside it needs interactivity. That pulls the entire component subtree into the browser bundle, and the application ends up shipping as much JavaScript as a client-rendered app while paying for server infrastructure too.

Keep the client boundary as low in the tree as possible. Push 'use client' down to the specific interactive leaf, not up to the container that happens to hold it.

A practical answer

If you are building something public-facing, use Next.js. If you are building something entirely behind a login, plain React is a defensible and simpler choice.

Either way, the framework matters less than the data model underneath it, which is where the genuinely expensive mistakes are made.

We cover this further on our Next.js development and web application development pages.