I built a React app from scratch once. I don't recommend it.
A few years ago I started a side project with nothing but create-react-app and a lot of confidence. Two weeks in, I had:
- Hand-rolled a router using
window.historyand aswitchstatement - Written my own "smart"
fetchwrapper with loading/error states copy-pasted into every component - No idea how I was going to make the homepage load fast, because everything rendered on the client
None of that is React's fault. React never promised to solve those problems. That's actually the whole point, and it's the part most explanations skip over.
React is a UI library, not an app-building kit
Here's the distinction that took me embarrassingly long to internalize: React only cares about one job — turning your data into what shows up on the screen, and keeping that in sync as data changes.
That's it. It doesn't know or care about:
- How the user got to this page
- Where your data comes from
- Whether this component rendered on a server or in the browser
- How your code gets bundled and shipped
That narrow focus is a feature, not a gap. It's why React works inside iOS apps (React Native), VR headsets (react-360), CLIs, and yes, regular websites. A library that stayed in its lane is a library that could go everywhere.
But "goes everywhere" has a cost: everywhere you take it, you have to bring your own answers for routing, data fetching, bundling, and rendering strategy. That's what I ran headfirst into.
Next.js is React's opinionated older sibling
If React is a box of really good LEGO bricks, Next.js is the instruction booklet, the base plate, and a few pre-built sections so you're not starting from a pile of loose pieces every time.
Concretely, Next.js makes decisions React refuses to make:
| Question React leaves open | Next.js's answer |
|---|---|
| How do I create a new page? | Add a file to the app folder |
| Where should this render — server or client? | Server, by default, unless you say otherwise |
| How do I fetch data without a loading spinner waterfall? |
fetch inside a Server Component, no client-side effect needed |
| How do I make images/fonts fast by default? | Built-in <Image> and font optimization |
| How do I deploy this thing? | It's just a Node app (or ships to any edge/serverless platform) |
You're still writing React components. JSX, props, hooks — all of that is unchanged. Next.js just refuses to let you agonize over the plumbing.
The tradeoff nobody puts in the marketing copy
Frameworks make you faster by making choices for you. That's great until you disagree with the choice.
Want a different routing paradigm? You're fighting the framework. Want to render everything client-side because your app is basically a Figma-style canvas tool? You can, but you're opting out of a lot of what makes Next.js "Next.js."
This is true of every framework, not a knock on this one specifically. Rails, Django, Laravel — same deal. You're trading flexibility for velocity. The question is never "is that a good trade," it's "is that a good trade for this project."
A marketing site with a CMS? Next.js's defaults are probably exactly what you want. A real-time collaborative whiteboard app? You'll be overriding a lot of those defaults, and that's fine too.
So when do you actually need Next.js?
A rough gut-check I use:
- Multiple pages/routes → a framework's router will save you real time
- You care about first-load performance or SEO → you want server rendering, which React alone doesn't give you
- You're fetching data that the page needs before it can render anything useful → you want that fetch to happen on the server, not after a spinner
- You're shipping to production, not just prototyping → you'll eventually need image optimization, code splitting, and a build pipeline anyway; might as well not build it yourself
If none of those apply — say, you're building a single embeddable widget — plain React (or even no framework at all) is a perfectly reasonable choice.
What's next
In the next post I'll actually spin up a Next.js project and show what "the server renders by default" looks like in practice — including the one gotcha that trips up almost everyone coming from plain React: not every component can use useState anymore, and that's on purpose.
If you've made the jump from plain React to Next.js (or bounced off it), I'd genuinely like to hear what surprised you — drop it in the comments.
Top comments (1)
Really useful explanation, especially for beginners. I’ve also been working with React and Next.js while building projects for Codecan.net, and this comparison made the difference much clearer.