When (and Why) You Should Not Use Next.js

Next.js has taken the web development world by storm, becoming a go-to framework for many developers and companies. With its built-in optimizations, SSR (Server-Side Rendering), ISR (Incremental Static Regeneration), and a thriving ecosystem, it seems like the ultimate solution for modern web applications.

But is it always the right choice?

Not necessarily.

Like any technology, Next.js has its downsides and scenarios where it may not be the best fit. In this article, I’ll break down when and why you should think twice before using Next.js.

1. You Just Need a Simple Static Site

If you’re building a basic static website—a personal portfolio, a landing page, or a small blog—you might be overcomplicating things by choosing Next.js. Yes, it supports static generation, but do you really need it?

Alternatives:

• Hugo, Jekyll, or Eleventy: These static site generators are faster, simpler, and easier to deploy for purely static content.
• Plain HTML/CSS/JS: If your site is truly small, why not go old-school? No build steps, no dependencies, just simple and efficient.

Choosing Next.js for a simple static site is like using a Swiss Army knife when all you need is a butter knife.

2. You Don’t Need Server-Side Rendering (SSR)

One of Next.js’s biggest selling points is SSR, which improves performance for dynamic content. But if your project doesn’t require server-side rendering, why add that complexity?

When You Don’t Need SSR:

• You have a content-heavy site that doesn’t change often (e.g., a marketing site).
• Your API responses don’t need to be computed on the fly.
• SEO is not a major concern (e.g., an internal dashboard).

Alternatives:

• React with Vite: Faster build times and better DX (Developer Experience) for client-side applications.
• Gatsby: If you need static generation with React, Gatsby’s plugin ecosystem may suit you better.

SSR is powerful, but if you don’t need it, you’re adding unnecessary complexity to your project.

3. The Build Time Gets Out of Control

Next.js can struggle with large-scale static site generation. If you have thousands of pages and are using SSG (Static Site Generation), build times can become painfully slow.

Signs Next.js May Be a Problem:

• Your build times keep increasing as content grows.
• Incremental static regeneration (ISR) is not sufficient for your needs.
• You have complex page dependencies that slow down re-renders.

Alternative:

• Astro: Designed to handle massive static sites with lightning-fast performance.
• Custom Build Pipelines: Sometimes, rolling your own solution gives better control over performance bottlenecks.

If long build times are blocking your deployment process, Next.js might not be the best tool for the job.

4. Vendor Lock-in & Hosting Constraints

Next.js works exceptionally well with Vercel, its creators' hosting platform, but that tight integration can sometimes feel like a golden cage. While you can deploy Next.js elsewhere (AWS, DigitalOcean, Cloudflare), it’s not always seamless.

Issues with Next.js Hosting:

• Some Next.js features (like ISR) work best on Vercel. Other hosting providers may require additional configuration.
• Custom server setups become tricky. If you want full control over routing, middleware, or caching, Next.js adds extra constraints.

Alternatives:

• Plain React + Express: If you need full control over your server, using React with a custom backend might be a better option.
• SvelteKit or Remix: Both offer SSR/SSG but provide more flexibility in hosting choices.

If you don’t want to feel boxed into a specific hosting provider, Next.js may not be ideal.

5. You Prefer a Simpler Developer Experience

Next.js is powerful but comes with a learning curve. Routing, API routes, server components, middleware—these features are great, but they can also feel like a lot if you just need a straightforward React app.

Common DX Frustrations with Next.js:

• Opinionated file-based routing: Convenient but limiting if you want custom structures.
• Mixing frontend and backend logic: API routes can lead to tightly coupled logic.
• Performance optimizations can be tricky: Automatic optimizations are great—until they aren’t, and you have to manually fine-tune things.

Alternatives:

• React + Vite: If you want a modern React setup with blazing-fast builds and full flexibility.
• Remix: If you need SSR but want a simpler, more straightforward developer experience.

Sometimes, less is more. If Next.js feels like overkill for your project, it probably is.

So, Should You Use Next.js?

The answer isn’t black and white. Next.js is an amazing framework—but only when used for the right use case.

You probably shouldn’t use Next.js if:

? You’re building a simple static site.

? You don’t need server-side rendering.

? Your build times are becoming a problem.

? You want full control over hosting.

? You prefer a simpler development experience.

On the other hand, if you need hybrid rendering, excellent performance, and a strong developer ecosystem, then Next.js remains one of the best choices out there.

The key takeaway? Choose the right tool for the job. Don’t just jump on the Next.js bandwagon because it’s popular - make sure it’s the best fit for your project.

What’s your experience with Next.js? Have you ever regretted using it, or do you think it’s the ultimate framework? Let’s discuss in the comments!