Next.js: When It's Worth It, When It's Overkill

Next.js: When It's Worth It, When It's Overkill (After Building Several Projects)

I remember trying Next.js for the first time. Coming from React + Vite, my immediate reaction was "wow, this feels more proper." Server components, file-based routing, image optimization - all out of the box. But after building 3 projects with Next.js, I realized: not every project fits Next.js. And this blog? It's built with React + Vite, not Next.js.

Why? That's what I want to talk about. Not a marketing review - but actual experience using it, when Next.js saved my life, and when it wasted my time.

---

What Next.js Makes Easy

1. Zero routing setup.

In React + Vite, you need to install react-router, configure routes, set up layouts, handle nested routes. In Next.js? Create a folder app/blog/[slug]/page.jsx - done. The URL automatically becomes /blog/your-slug. File-based routing lets you focus on writing code, not config.

2. SEO becomes natural.

This is the biggest reason people switch to Next.js. A standard React SPA does client-side rendering - Google bot sees an empty page, then JS loads, then content appears. Next.js uses Server-Side Rendering (SSR) or Static Site Generation (SSG). The bot sees complete HTML with content immediately.

For a blog like this, SEO is everything. SSR = your articles get indexed faster by Google.

3. Built-in image optimization.

Next.js component automatically generates responsive images - WebP, lazy loading, different sizes for different screens. I once tried implementing this manually in Vite using srcset + sharp. 2 days of work. Next.js? One prop: priority or not. Done.

4. API routes in one place.

You don't need a separate backend deployment for simple APIs. Create a file api/route.js inside your Next.js project, and it becomes an endpoint. For MVPs or small SaaS, this reduces deployment complexity significantly.

5. Vercel deployment = 1 click.

Push to GitHub, Vercel auto-deploys, global CDN, free SSL, built-in analytics. No need to set up Docker, nginx, or SSL certificates manually. For indie hackers, this eliminates a huge mental burden.

---

But Next.js Has Downsides Nobody Talks About on the Landing Page

1. Steeper learning curve than you'd expect.

Next.js 14+ is not regular React. You need to understand:
• Server Components vs Client Components (when to use "use client")
• Server Actions
• Caching behavior (this one gave me the most headaches)
• App Router vs Pages Router (some still use the old one)

I once wasted 4 hours debugging why useState wasn't working - turned out I forgot to add "use client" at the top of the file. Trivial, but if you're new to Next.js from Vite, it's frustrating.

2. Caching can drive you insane.

Next.js is extremely aggressive about caching. You update data, refresh the page, but the old data still shows. Why? Because Next.js caches fetch results by default. You need to understand revalidate, no-store, dynamic = 'force-dynamic', and when to use which.

For a static blog, caching is great. For applications with real-time data (dashboards, chat, analytics), Next.js's default caching becomes an enemy, not a friend.

3. Vendor lock-in to Vercel.

Next.js is open-source, but certain features (Image Optimization, Edge Functions, ISR) are optimized for Vercel. You can self-host with Docker, but some features don't work perfectly or need extra configuration.

If you deploy to Vercel, everything is smooth. If you want to move to your own server or another platform, there's a non-trivial migration effort.

4. Larger bundle size.

Next.js ships framework code that isn't small. For a simple blog like MSNCode, React + Vite produces a smaller bundle. Next.js adds overhead that makes it overkill for small projects.

5. Over-engineering for simple projects.

This blog uses React + Vite + Supabase Edge Functions. Why not Next.js? Because:
• This blog doesn't need SSR (SEO is handled via dynamic meta tags + sitemap generated in Edge Functions)
• Routing only needs react-router (15 pages)
• No heavy image processing
• Deployment is simpler: Vite build → Vercel static hosting

Using Next.js for this blog would be like using a truck to buy watermelon. It works, but it's overkill.

---

When You SHOULD Use Next.js

1. SaaS or e-commerce that needs SEO.

Marketplaces, online stores, directories - all need pages indexed by Google. Next.js SSR makes your products appear in search results.

2. Applications with many dynamic pages.

Dashboards, admin panels, CMS, multi-user platforms. Next.js routing keeps the project structure clean.

3. You need API + frontend in one repo.

Indie hackers who want to ship fast: Next.js API routes = no separate backend deployment for simple endpoints.

4. You're already familiar with React.

If you're a React developer, Next.js is a natural progression. But learn the Server Components concept first - don't assume it works exactly like regular React.

---

When You Should NOT Use Next.js

1. Static blogs or simple landing pages.

Vite + React, or even Astro, is lighter and faster. If content doesn't change in real-time, you don't need SSR.

2. Real-time applications (chat, live dashboards).

Next.js caching creates more problems than it solves. You'll spend time fighting the cache instead of writing features. For this, React + Vite + WebSocket is more straightforward.

3. You're new to React.

Next.js makes React concepts harder because it adds a layer of abstraction. Learn React fundamentals first, then Next.js.

4. You need full control over the server.

If you need custom nginx configs, persistent WebSockets, or background jobs, Next.js + Vercel is too opinionated. Use Express/FastAPI + a React SPA.

5. Your team isn't familiar with React.

If your team uses Vue, Svelte, or Laravel, Next.js is not the answer. Don't force a stack just because of hype. Use what your team knows well.

---

Quick Comparison

| Criteria | Next.js | React + Vite |
|---|---|---|
| SEO | ✅ SSR/SSG built-in | ⚠ Needs manual setup (meta tags, sitemap) |
| Routing | ✅ File-based, automatic | ⚠ Manual with react-router |
| Bundle size | ⚠ Larger | ✅ Smaller |
| Caching | ✅ For static content | ✅ You control it |
| Learning curve | ⚠ Steep (Server Components, caching) | ✅ Flat, familiar |
| Deployment | ✅ Vercel 1-click | ✅ Static hosting anywhere |
| Real-time apps | ❌ Cache makes it hard | ✅ More straightforward |
| Image optimization | ✅ Built-in | ⚠ Manual |
| Best for | SaaS, e-commerce, dashboards | Blogs, landing pages, SPAs |

---

An Honest Closing

Next.js is a powerful tool. But a powerful tool doesn't mean it's right for every project. I use Next.js for SaaS that needs SEO + API routes. I use Vite for this blog. I use Express + React for real-time dashboards.

Choose your stack based on project needs, not based on what's trending on Twitter.

If you're still unsure: start with Vite. If you later need SSR or more serious SEO, migrating to Next.js isn't that hard. But if you start with Next.js and it turns out to be overkill, migrating back is a much bigger headache.