Next.js is React plus the decisions React deliberately leaves open - routing, rendering strategy, bundling, data fetching - and the reason it dominates is that those decisions are tedious to make well and expensive to make badly.
React is a library for building interfaces and nothing else. That focus is a genuine virtue and it means every real application needs answers to a dozen questions React does not address. A framework supplies them, and the trade is that you inherit its opinions along with its solutions.
Table of contents
- What it actually adds
- Rendering strategy, the decision that matters most
- The costs, stated plainly
- When to choose it and when not to
- Deploying it without surprises
- How this fits the rest of the stack
- FAQ
What it actually adds
- File-system routing. Directory structure defines URLs, with nested layouts that persist across navigations rather than remounting.
- Multiple rendering strategies per route. Static generation at build time, server rendering per request, incremental regeneration that rebuilds pages on a schedule or on demand, and client rendering - chosen page by page rather than for the whole application.
- Server Components. Components that execute on the server and send no JavaScript to the browser at all. This is the largest architectural change in the framework in years and the one that requires the most unlearning.
- Data fetching in components. Making a component async and awaiting data directly, rather than orchestrating fetches in effects.
- Server Actions. Calling a server function from client code without hand-writing an API route for every mutation.
- Built-in optimisation. Automatic image resizing and format selection, font handling, script loading strategy, and code splitting per route.
- Route handlers and proxying. API endpoints and request interception in the same project as the frontend.
Individually, each of these is something you could assemble yourself. Collectively, assembling and maintaining them is a job nobody wants.
Rendering strategy, the decision that matters most
Getting this right per route is most of what performance work in this framework consists of, and the defaults are not always what you want.
Static is the correct choice far more often than people assume. Marketing pages, documentation, blog posts, product pages, anything where the content is the same for every visitor. It is the fastest possible option, it costs nothing per request, and it cannot fail at runtime because there is no runtime.
Incremental regeneration covers content that changes but not per visitor: a catalogue that updates hourly, an article that gets edited. You get static performance with a freshness window, and on-demand revalidation lets a CMS trigger the update on publish.
Server rendering is for genuinely per-request content: a logged-in dashboard, personalised results, anything reflecting the current user. It costs compute on every request, which is where hosting bills come from.
Client rendering suits interactive parts behind an authentication wall where SEO is irrelevant and the initial payload does not matter much.
The most common expensive mistake is server-rendering pages that could be static, usually because a single component somewhere reads a request header or a cookie and quietly opts the whole route into dynamic rendering. That one line can multiply your compute bill, and it is invisible unless you check which routes were actually built statically.
The costs, stated plainly
A large API surface. There is a lot to learn, the framework has changed significantly across major versions, and a great deal of published guidance describes patterns that are now discouraged. Searching for an answer frequently returns advice for a different architecture.
The server-client boundary. Server Components are genuinely powerful and genuinely confusing. Which code runs where, what can cross the boundary, and why a hook fails in one file and works in another are the questions that consume the most time when learning it.
Caching behaviour. The framework caches aggressively at several layers, and the interaction between them is the most common source of the report that a change is not appearing. Understanding what is cached where is not optional at any real scale.
Build times. Large sites with many statically generated pages take real time to build. Incremental adoption helps and the number still grows.
Portability, in the details. The core is portable and the edges are not. Image optimisation, incremental regeneration semantics, and edge middleware behave differently across hosts, and those differences surface after a migration rather than during it.
When to choose it and when not to
Choose it when the application is genuinely interactive and needs server rendering or good SEO. When the team already knows React. When you want one project containing both frontend and API rather than two. Or when you need per-route control over rendering, which is the strongest technical argument for it.
Choose something else when the site is genuinely static content - a marketing site, documentation, a blog. A static site generator produces the same output with a fraction of the machinery, and it will not accidentally start server rendering because someone read a cookie. When the team does not know React, since you would be learning two things. Or when the backend is substantial and in another language, where a separate API and a simpler frontend is a cleaner split.
The honest observation is that a lot of sites using it are content sites that never needed any of the dynamic capability, and are paying for the complexity in build times, caching confusion, and hosting cost.
Deploying it without surprises
Where it runs matters more here than for most frameworks, because the features that make it pleasant are the ones with host-specific implementations.
Fully static output deploys anywhere - it is just files, and any CDN-backed static host serves them. Fully server-rendered output is a Node process, which runs on any platform that runs containers. The awkward middle is incremental regeneration and image optimisation, which depend on the host implementing something specific.
Before migrating between hosts, test three things specifically on a staging domain: redirects and rewrites including precedence, on-demand revalidation with a real content change, and whether framework-optimised images are still being optimised rather than served at full size. Those three account for most post-migration problems, and all three fail quietly rather than loudly.
How this fits the rest of the stack
Rendering strategy is a hosting cost decision as much as a performance one, and it is worth seeing both numbers together. The RunxBuild hosting calculator prices static hosting, the running service, the database, and the bandwidth as separate items so the difference between static and server-rendered routes is visible. RunxBuild deploys Next.js services from a GitHub repository with build logs, environment variables per deploy, custom domains, rollback, and autoscaling, and static output with 120GB of bandwidth included.
Useful related references:
- Vite vs Next.js: Picking Without the Framework Argument
- Cloud Governance: The Framework That Keeps the Cloud Under Control
- Express vs Node: Express Is a Framework, Node Is a Runtime, and the Difference Is the One Most Blog Posts Skip
- Services on RunxBuild
FAQ
What does Next.js add to React?
The decisions React leaves open: file-system routing with nested layouts, per-route rendering strategies, Server Components that send no JavaScript, data fetching directly in components, Server Actions for mutations, built-in image and font optimisation, and API route handlers in the same project.
Which rendering strategy should I use?
Static wherever the content is the same for every visitor, which is more routes than most people assume. Incremental regeneration for content that changes but not per user. Server rendering only for genuinely per-request content like a logged-in dashboard, since it costs compute on every request.
Why did my page start server rendering unexpectedly?
Usually because a component somewhere reads a request header, a cookie, or search params, which opts the whole route into dynamic rendering. It is a one-line change with a large cost, and it is invisible unless you check which routes were actually built statically.
Is Next.js overkill for a blog or marketing site?
Frequently yes. A static site generator produces the same output with far less machinery, faster builds, no caching layers to reason about, and no risk of accidentally server rendering. The framework earns its complexity when routes genuinely need per-request rendering.
Is Next.js portable between hosting platforms?
The core is - static output is files and server output is a Node process. Image optimisation, incremental regeneration, and edge middleware depend on host-specific implementations. Test redirects, on-demand revalidation, and image optimisation on staging before switching, since all three fail quietly.