As a developer who’s been working in React for years, I didn’t expect to fall so hard for Next.js. But once I made the switch, I found myself saying, “Let’s just Next.js everything.”
It started with a side project, I tried next.js and I was hooked. The monorepo-friendly architecture, file based routing, and built-in server-side capabilities really enhanced my developer experience. From that point on, every new project began with npx create-next-app
But while Next.js is powerful, it’s not always the right choice. Here are a few real life lessons I’ve learned from switching from React to Next.js:
When to choose React?
1. Client-heavy applications? React might be your best bet.
I’ve found myself struggling in Next.js when building apps that are heavily dependent on client side interactions, like dashboards that don’t care much about SEO and load most of their data via APIs after render. In such cases, the server side magic of Next.js can sometimes get in the way, especially when managing state across dynamic routes or dealing with hydration mismatches.
2. Backend already deployed? Keep it simple with React.
If you’re only building the frontend and your backend lives elsewhere, React might be the easier and better choice. Next.js shines the most when it handles both frontend and backend logic like when I’m setting up API routes directly in the project. But if I only need to build frontend I would go with React.
When to choose Next.js?
1. SEO? Go with Next.js.
It’s not that React is bad for SEO, it’s just that Next.js gives you an extra edge. By generating HTML on the server before it hits the browser, Next.js helps web crawlers index your content more effectively.
I’ve seen improved page rankings and faster content discovery on projects where SEO was critical.
2. Monorepo-friendly and production-ready out of the box.
One of the things that made me fall in love with Next.js was how easy it is to scale. The file-based routing, API routes, middleware, and even app directory structure make it feel more cohesive and manageable, especially in a monorepo setup.
React doesn’t impose structure, which can be freeing or frustrating, depending on the size of the project.
🧭 Routing: Manual vs Magic
This was one of the first things that blew my mind.
In React, I was always setting up react-router-dom, mapping routes manually, and managing nested routes through config or wrappers. It worked, but it always felt like setup I had to do before actually building anything.
In Next.js, you just drop a file in your app/ directory and it becomes a route. Done. Need dynamic routes? Just use brackets like [id].tsx.
It feels like the framework wants you to go fast.
The best part? Clean URLs and layouts come naturally, and you can even create shared layouts without boilerplate. That was a game changer.
🚀 Performance: Built-in Wins
Another thing that made me "Next.js everything" was how much performance tuning I didn’t have to do.
With React, I’d often reach for tools like React.lazy, Suspense, Webpack plugins, manual chunking, or image optimization libraries.
With Next.js, many of those concerns are handled for you:
- ✅ Automatic code splitting.
- 🖼️ Built-in image optimization with
next/image - 🌍 Static content served via CDN
- ✨ Automatic font optimization
So, Should You Next.js Everything?
Not necessarily. React is still great and in many cases, it’s exactly what you need.
But if you’re building a full-stack app, care about performance and SEO, or want a better developer experience out of the box, Next.js makes a compelling case.
For me, Next.js is my go-to for new projects but there are still times when React.js is the better fit, depending on the project’s needs.
Hi, I'm Samit. A Software Developer and a freelancer who’s always on the lookout for exciting, real world projects to build and contribute to. I love hearing from people, whether it’s to collaborate, share ideas, or work together.
If you're looking to hire a passionate developer or even if you just want to say hi, feel free to check out my portfolio and reach out. I'd love to connect!
Top comments (0)