Choosing Your React Framework in 2025: Understanding Next.js Trade-offs

I love Next.js. It's been my framework of choice since my first tiny contribution in 2017.

Yesterday, I joined a team discussion about which React framework to choose. In 2025, that decision is harder than ever, with so many excellent alternatives available.

While Next.js is recommended by React themselves, and is a very popular choice, the not-so-good parts are often left out on platforms like LinkedIn and YouTube.

I plan to write about the good things about Next.js 15 in the future, but here are some challenges I still face using it today.

Next.js 15 and React Server Components (RSC)

It's not just me who has doubts about (overhyped) React Server Components, which on paper look fantastic, however...

RSC is the most painful new React API in the State of React survey.

Complaints:
- Hard to test.
- Hard to debug.
- Hard to reason about.
- Confusing mental model.
- Seems designed to sell Vercel.
- Some think only Next.js supports RSC.
- More complexity for little benefit. pic.twitter.com/HT5DzXlK3t

— Cory House (@housecor) February 12, 2025

Middleware Issues

Edge Runtime Limitations

• Restricted Node.js API usage:
  The Next.js Edge Runtime explicitly excludes many native Node.js APIs (such as fs, net, etc.), making tasks like direct database connections or session management impossible in middleware.
  Verified by the official documentation:
  Vercel's Edge Middleware Limitations and the Next.js Edge Runtime API Reference.

• Authentication compatibility issues:
  Third-party libraries that depend on Node.js APIs (for example, MongoDB drivers, Firebase Admin SDK, or Redis clients like ioredis) often face compatibility issues when used in middleware. Several GitHub discussions note struggles with using these libraries in the Edge Runtime.
  For example, this GitHub discussion highlights user-reported issues regarding such limitations (the core restrictions are detailed in the official docs).

Good news: Node.js runtime support for middleware is merged! The PR #75624 by the Next.js team enables middleware to run with full Node.js API support, addressing many of the current limitations. Broader discussions on this topic are tracked in GitHub Discussion #71727.

Single Middleware File Restriction

• Single entry point:
  Next.js supports only one middleware file (typically middleware.ts or middleware.js placed in the project root or within the src directory). This forces developers to consolidate all middleware logic into one file. Although not exhaustively documented in a single article, this constraint is implicit in the official Next.js Middleware docs and has been noted in various user reports. Having to use matches and then manually filter is a horrible developer experience.

Implementation Problems

Inconsistent Execution

• Middleware Execution Issues:
  In GitHub Issue #58025, users reported that middleware sometimes doesn't execute as expected in Next.js v14.2.4, occasionally requiring a hard refresh to function correctly. While this isn't solely a file placement issue, it underscores the importance of proper middleware configuration.

• Redirect Behavior in Middleware:
  GitHub Issue #59218 discusses problems with middleware redirects, where users experienced unexpected behaviour due to browser caching. This highlights the need for careful implementation and a thorough understanding of middleware behaviour.

Authentication Compatibility

• Challenges with authentication libraries:
  Libraries like NextAuth.js have noted issues when used in middleware—largely because the Edge Runtime lacks certain Node.js APIs (e.g., Node's crypto module) required by these libraries.
  For more details, refer to the Next.js Edge Runtime API Reference.

Fetch API and Monkey Patching Issues

Global Fetch Modifications

• Next.js extends the Web fetch:
  Next.js extends the standard Web fetch() API to allow each server-side request to set its persistent caching and revalidation semantics. More details are provided in the Next.js fetch documentation.

• Memory leaks and compatibility issues:
  Modifications to the global fetch (supporting features like caching and Server Actions) have sometimes led to memory leaks.
  A documented example is available in GitHub Issue #64212.

• Interference with error handling and third-party libraries:
  Monkey-patching fetch can conflict with libraries that rely on or modify it. For example, discussions on Reddit highlight how such modifications may disrupt expected error handling.
  See this Reddit thread on monkey-patching fetch.

MSW Integration Challenges

• Server-side interception issues:
  Many developers have reported challenges with server-side request interception when integrating Mock Service Worker (MSW) with the new App Router in Next.js 13+. These issues are likely due to the restricted Edge Runtime, which lacks Node.js APIs (such as the http/https modules) required for full HTTP interception.
  Learn more about MSW on their official documentation.

No Platform Adapter (Unlike Remix, Svelte, and Astro)

There is an initiative called OpenNext, but it appears to be playing catchup. Vercel remains the best platform to host Next.js, so having adapters for other platforms might introduce conflicts of interest.

Backward Compatibility Bloat

• Legacy systems maintained alongside new features:
  Next.js continues to support legacy systems (e.g., the Pages Router and Babel) even as it introduces new paradigms like the App Router. This coexistence increases overall complexity.
  Official Next.js Pages Documentation.

• SWC vs. Babel compatibility:
  Although Next.js introduced the SWC compiler for performance improvements, Babel compatibility is still maintained—which adds to the bloat.
  Next.js 12 Blog on SWC.

Modern Alternatives

Astro for Static Sites

• Performance benefits:
  Astro claims to load static content up to 40% faster and deliver 90% less JavaScript than Next.js, making it an attractive option for content-heavy sites.
  Learn more about Astro.

TanStack Router for SPAs

• Superior type safety and flexibility:
  TanStack Router offers excellent type safety and flexible routing patterns, and being client-side first means you can sprinkle in server actions with server validation when needed.

  Bonus: it uses lightning-quick Nitro and Vite to bundle and deploy your application.

TanStack Framework Comparison.

Remix/React Router 7/?

• Should have been number one to me:
  Backed by Shopify, with Ryan and Michael leading the way, this would have been my top choice a year ago. I love everything about their approach, from open planning sessions to clear community communication and a commitment to web standards.

  However, the merging of Remix and React Router is a bit confusing at best. During this transition period, it’s a tough sell to recommend it to clients. Hopefully, when things stabilize and we have a clearer picture of what’s what it will be worth another look.

Development Experience Issues

Caching Complexities

• Inconsistent caching behavior:
  Next.js 14's aggressive caching sometimes led to stale data. Although Next.js 15 disabled caching by default to address these complaints, new issues have emerged in some cases.
  See community threads on GitHub discussions.

Architectural Challenges

• Hydration mismatches in Server Components:
  Blending server and client components can lead to hydration mismatches that are challenging to debug.
  Next.js Server Components Documentation.

• Mandatory file-based routing quirks:
  The requirement that each page have a page.tsx file can be confusing and may lead to accidental bundling of server-only code into client bundles.
  Official Next.js Pages Documentation.

Upgrades and Dependency Issues

• Dependency conflicts during upgrades:
  Some users have experienced issues when migrating between major versions (e.g., from Next.js 14 to 15), especially as many libraries are still catching up with changes introduced in React 19. In some cases, developers have resorted to workarounds like running npm install --legacy-peer-deps to bypass strict peer dependency checks.
  See discussion on this workaround in the shadcn/ui repository.

Despite these challenges, Next.js remains a powerful and flexible framework that continues to evolve.

It will improve, and hopefully, one can be seamlessly deployed on many platforms, not just Vercel.

With a huge ecosystem, it's still my go-to framework.

However, modern alternatives like Astro and TanStack Router may offer more focused solutions for developers who find these pain points too limiting.

Ultimately, the right tool depends on your specific use case and priorities.