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

Original Article ↗ Hacker News Discussion ↗

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.