Is Next.js falling off? why some devs are bailing, and what they’re building instead

next.js was once the golden child of react frameworks. now? not so much. here’s why the hype is fading and what’s replacing it. Section 1: Intro the fall of a frontend darling Once upon a time, every React dev and their dog was shipping sites with Next.js. It was clean. It was fast. It made static generation cool again. You threw your .mdx files into a pages/ directory, ran next build, and went on with your life. Need some SSR? BoomgetServerSideProps() had your back. Need an image optimizer? Already built-in. Life was good. Then came the App Router. Then came React Server Components. Then came Middleware. Then came… existential dread. Suddenly, what used to be a dev-friendly framework started feeling like a PhD thesis in distributed systems. Next.js started promising everything, but delivering it through more abstraction, more configuration, and more Vercel-specific opinions. And while big companies might love it for its power and flexibility, smaller teams and indie devs? They’re packing their bags. “Next.js is slowly becoming Kubernetes for frontend.” some frustrated dev on Reddit, probably This article isn’t a hit piece. It’s a dev-to-dev breakdown of why some folks are ditching Next.js in 2025 and where they’re going instead. Spoiler: Astro is winning hearts, and SvelteKit is quietly stealing the DX crown. Ready to dive in? Let’s debug the hype. Section 2: the great shift to complexity It started with a pages/ folder. Life was good. Then came app/, and things got... philosophical. Next.js earned its fame by making complex things simple static generation, dynamic routing, SSR all with a low cognitive load. But as of 2025, that simplicity is gone. Instead, devs now open a new Next.js project and immediately ask: “Wait, do I use pages or app? What works with Server Components again? Why is everything async now?” The App Router was supposed to streamline routing and enable powerful patterns. Instead, it split the ecosystem in two: Old projects clinging to pages/ New projects fumbling through app/, layout.tsx, and a dozen loading/error states Next.js began layering in features like: Server Components with strict client/server boundaries Middleware for routing logic (at the edge!) Server Actions replacing API calls Edge runtime that works great… unless you want to use fs Suddenly, developers needed to know how React internals work just to build a contact form. The worst part? The “magic” that once made Next.js appealing now feels like dark magic. Error messages are cryptic. Tooling is fragile. And every update threatens to break your stack if you don’t read the entire changelog and sacrifice a goat to the Vercel gods. It’s no longer about “how fast can I build?” It’s “how much of this do I really need to understand just to render a page?” Section 3: server components great idea, messy rollout Let’s get one thing straight: React Server Components (RSCs) are brilliant in theory. You get to offload work to the server, stream HTML faster, and keep bundles lean. Your client-side JavaScript gets smaller, performance improves, and you only send the code you actually need. It’s like React, but with built-in steroids. Who wouldn’t want that? But then you try to use them. Suddenly, every file starts with “is this a server component or a client component?” You sprinkle use client like salt across your files. You’re debugging hydration issues because your Navbar decided to freak out, and importing even a small onClick handler now makes your entire file “go client.” It gets worse: You can’t use hooks like useState or useEffect in server components. You’re manually splitting components like it’s 2015 again. Some npm packages? Yeah, they’re not compatible. Good luck. Devs expected clarity, but what they got was a tangled set of rendering rules, performance tradeoffs, and gotchas. “I feel like I need a React priest to absolve me before using use client.”probably every dev who tried server components for the first time And because RSCs are still technically “experimental,” the docs are evolving, the examples are limited, and community support is… confused, to say the least. This isn’t to say RSCs won’t be amazing. They probably will one day. But right now, they feel like beta features pushed into production expectations. Section 4: the vercelification of everything Next.js and Vercel go together like TypeScript and overly confident juniors. One was built by the other. And in theory, that tight integration is great it means seamless DX, optimized deployment, and performance wins out of the box. But in practice? It’s starting to feel like Next.js isn’t just powered by Vercel… it’s becoming a Vercel product rather than a truly independent framework. Let’s break that down. When you use Next.js on Vercel: Edge Functions? Zero config. Image optimization? Magic. ISR (Incremental Static Regeneration)? Just works. But try deploying the same app anywhere else AWS, Netlify, your own VPS and suddenly:

May 9, 2025 - 09:26

Is Next.js falling off? why some devs are bailing, and what they’re building instead

next.js was once the golden child of react frameworks. now? not so much. here’s why the hype is fading and what’s replacing it.

Section 1: Intro the fall of a frontend darling

Once upon a time, every React dev and their dog was shipping sites with Next.js. It was clean. It was fast. It made static generation cool again. You threw your .mdx files into a pages/ directory, ran next build, and went on with your life. Need some SSR? BoomgetServerSideProps() had your back. Need an image optimizer? Already built-in. Life was good.

Then came the App Router.
Then came React Server Components.
Then came Middleware.
Then came… existential dread.

Suddenly, what used to be a dev-friendly framework started feeling like a PhD thesis in distributed systems. Next.js started promising everything, but delivering it through more abstraction, more configuration, and more Vercel-specific opinions.

And while big companies might love it for its power and flexibility, smaller teams and indie devs? They’re packing their bags.

“Next.js is slowly becoming Kubernetes for frontend.” some frustrated dev on Reddit, probably

This article isn’t a hit piece. It’s a dev-to-dev breakdown of why some folks are ditching Next.js in 2025 and where they’re going instead. Spoiler: Astro is winning hearts, and SvelteKit is quietly stealing the DX crown.

Ready to dive in? Let’s debug the hype.

Section 2: the great shift to complexity

It started with a pages/ folder. Life was good.
Then came app/, and things got... philosophical.

Next.js earned its fame by making complex things simple static generation, dynamic routing, SSR all with a low cognitive load. But as of 2025, that simplicity is gone. Instead, devs now open a new Next.js project and immediately ask: “Wait, do I use pages or app? What works with Server Components again? Why is everything async now?”

The App Router was supposed to streamline routing and enable powerful patterns. Instead, it split the ecosystem in two:

Old projects clinging to pages/
New projects fumbling through app/, layout.tsx, and a dozen loading/error states

Next.js began layering in features like:

Server Components with strict client/server boundaries
Middleware for routing logic (at the edge!)
Server Actions replacing API calls
Edge runtime that works great… unless you want to use fs

Suddenly, developers needed to know how React internals work just to build a contact form.

The worst part? The “magic” that once made Next.js appealing now feels like dark magic. Error messages are cryptic. Tooling is fragile. And every update threatens to break your stack if you don’t read the entire changelog and sacrifice a goat to the Vercel gods.

It’s no longer about “how fast can I build?”
It’s “how much of this do I really need to understand just to render a page?”

Section 3: server components great idea, messy rollout

Let’s get one thing straight: React Server Components (RSCs) are brilliant in theory.

You get to offload work to the server, stream HTML faster, and keep bundles lean. Your client-side JavaScript gets smaller, performance improves, and you only send the code you actually need. It’s like React, but with built-in steroids. Who wouldn’t want that?

But then you try to use them.

Suddenly, every file starts with “is this a server component or a client component?” You sprinkle use client like salt across your files. You’re debugging hydration issues because your Navbar decided to freak out, and importing even a small onClick handler now makes your entire file “go client.”

It gets worse:

You can’t use hooks like useState or useEffect in server components.
You’re manually splitting components like it’s 2015 again.
Some npm packages? Yeah, they’re not compatible. Good luck.

Devs expected clarity, but what they got was a tangled set of rendering rules, performance tradeoffs, and gotchas.

“I feel like I need a React priest to absolve me before using use client.”probably every dev who tried server components for the first time

And because RSCs are still technically “experimental,” the docs are evolving, the examples are limited, and community support is… confused, to say the least.

This isn’t to say RSCs won’t be amazing. They probably will one day. But right now, they feel like beta features pushed into production expectations.

Section 4: the vercelification of everything

Next.js and Vercel go together like TypeScript and overly confident juniors. One was built by the other. And in theory, that tight integration is great it means seamless DX, optimized deployment, and performance wins out of the box.

But in practice? It’s starting to feel like Next.js isn’t just powered by Vercel… it’s becoming a Vercel product rather than a truly independent framework.

Let’s break that down.

When you use Next.js on Vercel:

Edge Functions? Zero config.
Image optimization? Magic.
ISR (Incremental Static Regeneration)? Just works.

But try deploying the same app anywhere else AWS, Netlify, your own VPS and suddenly:

ISR breaks
Middleware throws errors
Edge runtimes fail silently
You spend half a day tweaking configs and still don’t get full parity

The “just works” DX slowly turns into “just works on Vercel.”

This is a major turnoff for devs who care about portability and vendor neutrality. Nobody wants to feel like their frontend stack is locked into a single platform, especially when that platform is starting to charge for bandwidth like it’s the 2000s.

And it’s not just devs. Teams working at scale have noticed the same thing:

“Our app ran flawlessly on Vercel, but moving it to AWS required reengineering half our routes and APIs.” anonymous CTO, startup with scars

To be clear: Vercel is doing incredible work. Their performance benchmarks are solid. Their team ships fast. But when the framework and the host become inseparable, the open-source spirit starts to fade and devs start looking elsewhere.

Section 5: what indie devs and startups want instead

Not every developer is trying to build the next Spotify.
Some of us just want to launch a landing page, a blog, a SaaS dashboard, or a tiny side hustle without battling the React boss level of abstractions.

That’s where Next.js is losing hearts. As the framework leans deeper into enterprise-scale complexity, indie devs, freelancers, and small teams are walking away in search of simplicity, speed, and sanity.

So where are they going?

Astro

Astro is the darling of the “island architecture” movement. It ships zero JavaScript by default, lets you mix and match frameworks (React, Svelte, Vue, etc.), and builds sites that are stupidly fast.

“We rebuilt our docs from Next.js to Astro and cut build times by 60%.”
actual quote from multiple dev blogs

SvelteKit

SvelteKit is like what Next.js used to be only faster and friendlier. It compiles away your components, offers a tight bundle size, and doesn’t make you fight your framework to get results. You can build entire apps with fewer files, less boilerplate, and zero use client.

Remix

Remix feels like React rediscovered its roots. It’s built on web fundamentals form submissions, loaders, actions and it embraces progressive enhancement. If you know HTML and understand fetch(), you’ll grok Remix quickly.

SolidStart

For devs who want the bleeding edge, SolidStart (based on Solid.js) offers fine-grained reactivity and near-native performance. It’s not for everyone, but it’s blazing fast and laser-focused on efficiency.

In short: The demand isn’t for more features it’s for less friction.
The frameworks winning right now are the ones that let devs get in, build fast, and get out without reading RFCs or deciphering hydration errors.

Next.js still has the tools but the indie dev crowd is asking: “Why should I use a framework that wants me to build like Netflix when I’m just trying to build a blog?”

Section 6: who should still use next.js?

Look, just because a bunch of devs are jumping ship doesn’t mean the ship’s sinking.

Next.js is still an incredibly powerful framework when used in the right context. For large teams, enterprise-scale apps, and performance-critical experiences, it can still be the MVP (and not the startup kind most valuable platform).

Perfect for:

Enterprise teams that need SSR, API routes, auth, edge functions, and everything under the sun in a single stack
Startups already deep into the Vercel ecosystem why fix what isn’t broken?
React-heavy teams that are okay investing in learning RSCs and the new routing paradigm

Why it still slaps for them:

Best-in-class documentation and community support
Powerful built-in features like ISR, middleware, and image optimization
Easy DevOps if you’re deploying to Vercel (which many are)
Seamless integration with modern React features

You probably shouldn’t ditch Next.js if:

You’re building a complex dashboard with lots of dynamic content
You need granular control over server-side rendering
You already have a team that knows and loves it

It’s like Kubernetes it’s not bad, it’s just not for everything. If you’re trying to run a lemonade stand, you probably don’t need a whole shipping container and a CI/CD pipeline.

TL;DR: Next.js isn’t dead it’s just growing up, and some devs are realizing they’re not raising that kind of child.

Section 7: what to watch in 2025

If 2023 was the year of “Next.js dominates,” and 2024 was the year of “wait, is it too much?”, then 2025 is shaping up to be the year of rethinking everything. Framework fatigue is real, and developers are demanding fewer layers, better defaults, and more control.

1. The rise of edge-first runtimes

Deno, Bun, and Cloudflare Workers are eating traditional server environments alive. They’re faster, simpler, and less bloated. Frameworks like Fresh (Deno) and others are leaning hard into this “edge-native” approach, where serverless meets instant execution.

2. Vite > Webpack (and the ecosystem knows it)

If you’re still using Webpack, blink twice. Vite is now the baseline for DX speed and dev server performance. Most modern frameworks (Astro, SvelteKit, SolidStart, even some React starters) have embraced it, and it’s reshaping how dev tooling is built.

3. Less JavaScript, more HTML again

Astro, Eleventy, and others are reminding devs that shipping less JavaScript isn’t just an optimization it’s a philosophy. SSR is cool, but sometimes… a

in an HTML file is cooler.

4. Framework de-coupling

Dev teams are realizing the cost of lock-in. Whether it’s database clients, auth services, or hosting providers, developer freedom is the new hot commodity. The more “framework-agnostic” your stack is, the better.

5. Devs are moving from “meta-frameworks” back to basics

There’s a counterculture brewing: some developers are ditching frameworks entirely and going back to basics. Think: React + Express. Or even no React just native web components with some hydration sugar sprinkled on top.

2025 isn’t about the biggest, most feature-packed framework.
It’s about developer experience, clarity, and velocity.

If your framework makes you feel like you need a roadmap just to build a form… devs will find something else.

Section 8: Conclusion is next.js dead?

Let’s kill the suspense: No, Next.js isn’t dead.
But it’s definitely changing, and not everyone wants to come along for the ride.

It’s still an insanely powerful framework with first-class support for things like SSR, SSG, middleware, and serverless functions. It’s got the Vercel engine behind it, a gigantic community, and arguably the best docs in the React universe.

But here’s the kicker:
Next.js no longer serves everyone.
It used to be the Swiss Army knife for all devs bloggers, indie hackers, and Fortune 500 teams alike. Now, it’s more like a Swiss Army tank. Powerful, but probably overkill for your portfolio site.

And that’s okay.

If you love Next.js and it works for your use case keep using it.
But if you’re building fast, iterating solo, or trying to keep things minimal? There are better tools for your vibe in 2025.

The frontend world is wide open again. You’ve got Astro, SvelteKit, SolidStart, Remix, and even plain old HTML making a comeback. You’re no longer locked into one way of thinking.

Choose the tool that fits your brain not the one that fits someone else’s roadmap.

Section 9: helpful links and dev goodies

Whether you’re sticking with Next.js, jumping ship, or just spectating the framework drama from your digital bunker, here’s a stack of solid resources to keep you sharp and ship-ready:

Official docs & deep dives:

Real dev hot takes:

Framework playgrounds:

Just good reads:

You don’t need to pick a side you just need to pick what works for you.
And if all else fails? Go old school with a static/index.html and vibes.