Next.js3 min read
Next.js vs React: what you are actually choosing between
The question is never 'React or Next.js'. It is 'do I want to own routing, rendering, bundling and SEO myself, or not'.
Seven frontend decisions are hard to reverse later: the framework, the rendering strategy, the styling approach, the state model, the data layer contract, the testing strategy, and the deployment target. Each should be written down with its reasoning so the next engineer inherits the argument, not just the outcome.
This pair travels together. Choosing Next.js largely settles rendering; choosing a Vite SPA settles it differently. The deciding question is whether unauthenticated visitors and search engines need to see your content — if so, server rendering is not optional.
Record what you assumed. 'We chose a client-only SPA because 100% of traffic is authenticated' is a decision that can be revisited honestly when marketing asks for a public pricing page.
| Approach | Strength | Cost |
|---|---|---|
| Utility CSS (Tailwind) | Fast, no naming, small production CSS | Verbose markup, needs component discipline |
| CSS Modules | Plain CSS, scoped, zero runtime | Manual design token wiring |
| CSS-in-JS (runtime) | Dynamic styling from props | Runtime cost, server component friction |
| Zero-runtime CSS-in-JS | Typed styles, no runtime | Smaller ecosystem, build complexity |
Any of these can produce an excellent result. What cannot is using three of them in one codebase, which is what happens when the decision is never actually made.
Decide where server data lives and how it gets there before the second engineer joins. Server components, a query library, or a hand-rolled fetch layer are all defensible; mixing all three per-feature is not.
Decide what CI blocks on. A pipeline that runs tests but does not fail the merge is decoration. Our default for client projects: type check, lint, unit tests for logic, and a handful of end-to-end tests covering the flows that generate revenue.
Managed platform, container on a cloud provider, or static export to a CDN. This decision constrains which framework features you can use, so make it early and verify your feature set against it before you depend on something the target cannot run.
“Write the decision, the alternatives considered, and the assumption that would make you change your mind. Three paragraphs, in the repository, dated.”
— ROVQIX architecture decision record template
A short markdown file in the repository capturing a decision, the context, the options considered and the consequences. It costs ten minutes and saves the next team from re-litigating a choice without knowing why it was made.
Pick the one your team already knows, or the one that is cheaper to reverse. Familiarity and reversibility are underrated tie-breakers compared with benchmark differences you will never notice.
When the assumption behind one stops holding — the app gains public pages, the team triples, traffic grows tenfold. Not on a schedule, and not because something new trended.
Yes, and a significant one. It pays off with multiple deployable apps sharing code, and adds tooling overhead when there is only one app. Decide based on how many things you actually deploy.
Harshal Patel
Founder & Lead Engineer, ROVQIX
Harshal leads engineering at ROVQIX, where he has shipped production Next.js, Node.js and PostgreSQL systems for startups, SaaS teams and ecommerce brands. He writes about the trade-offs behind architecture decisions rather than the framework of the week.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
The question is never 'React or Next.js'. It is 'do I want to own routing, rendering, bundling and SEO myself, or not'.
Every codebase is well organised on day one. The question is what it looks like after forty feature requests have been bolted onto the same Button.
Microservices solve an organisational problem with a distributed systems bill. If you do not have the organisational problem, you just have the bill.
No spam. Just the occasional case study and craft breakdown.