One year with Next.js App Router and why we're moving on

Original Article ↗ Hacker News Discussion ↗

Next.js’s App Router and React Server Components are drawing heavy criticism from developers who find them needlessly complex, brittle, and often worse for performance and UX than simpler alternatives. Many report better results with “boring” stacks like Vite + React + TanStack, traditional SPA architectures, or established full-stack frameworks such as Rails and Django, arguing that constant routing and data-loading innovations solve few real problems while adding migration and mental overhead. A minority defends Next.js as powerful when deeply understood, but even they acknowledge steep complexity, poor documentation around caching and hydration, and a growing sense that Vercel’s priorities are misaligned with everyday product needs.

Frustration with Next.js App Router & RSC

  • Many commenters report experiences matching the blog: App Router and React Server Components (RSC) add a “bucket load” of complexity for marginal or unclear benefit.
  • Key pain point: navigation causing full page remounts, losing client state and making fine‑grained loading UX (e.g., keeping some data visible while other parts load) difficult or impossible.
  • Several feel RSC solves a problem they never had; they’ve built successful React apps for years without it and see RSC as overengineering.

Preference for simpler stacks and SPAs

  • Strong current in favor of “boring” stacks: Vite + React + TanStack Query + a simple router (React Router, TanStack Router, Wouter).
  • Multiple people say that replacing Next with a custom or minimal router made their apps simpler and faster.
  • Some argue:
    • For SEO‑heavy sites: static generation or straightforward SSR + CDN caching.
    • For “apps”: lean into SPA + caching, possibly as PWAs, and accept a heavier initial bundle.

Routing & data loading philosophies

  • Debate over whether routers should orchestrate data fetching (to avoid waterfalls/N+1‑style issues) versus using a dedicated data layer (e.g., TanStack Query) and parent components.
  • Some praise modern “data routers”; others see this as scope creep and contributory to mental overhead.
  • One thread critiques the idea that routing needs repeated reinvention; others defend ongoing innovation to better coordinate data loading.

Performance, SSR, and UX

  • Disagreement over performance priorities:
    • Some ship multi‑MB SPAs and preload lots of data; users are happy because in‑app interactions are fast.
    • Others note this would be unacceptable for content sites (e.g., blogs).
  • Several say perf anxieties around things like CSS‑in‑JS are overblown in practice.

Ecosystem churn vs “boring” frameworks

  • Strong nostalgia for earlier React days (React Router + Redux) and for long‑stable ecosystems like Rails, Django, ASP.NET.
  • Perception that incentives (marketing, “thought leadership”) drive constant reinvention and architectural churn, at real cost to teams.

Views on Vercel/Next direction & adoption

  • Many see Next as a conceptual mess of modes and acronyms, with confusing caching and unfinished features, yet still missing basics like built‑in auth/i18n.
  • Some note they are “forced” into Next because it’s the only supported extension framework for certain enterprise products.
  • A minority defend Next/App Router, arguing that:
    • Issues often stem from mixing it with other data frameworks against its design.
    • Streaming HTML + RSC payloads and React caching solve some of the cited problems, albeit with a steeper learning curve.

Alternatives and related tools

  • Nuxt is praised but there’s anxiety about its acquisition by Vercel.
  • TanStack, Wouter, React Router v7, and simple backends (Spring Boot, Flask/FastAPI, Hono) come up as favored components.
  • One side discussion raises concerns about Bun’s stability and security; others are skeptical that it’s fundamentally sloppy, citing mainly crash bugs typical of young low‑level runtimes.