You should know this before choosing Next.js

Original Article ↗ Hacker News Discussion ↗

Perceived Benefits of Next.js

  • Strong conventions for routing, builds, linting, and bundling reduce bikeshedding and setup time.
  • Integrated API routes and middleware let frontend and backend share a single codebase and TypeScript types, which some teams find very productive.
  • SSR + React without learning a separate stack is attractive to React-only developers and agencies with Vercel/Netlify partnerships.
  • Considered familiar and “enterprise-like” for people from .NET/Java ecosystems, and is the de facto extension framework for many SaaS products.

Developer Experience & Performance Issues

  • Multiple complaints about extremely slow dev builds and HMR (multi‑second reloads even on high-end machines), with a long-standing GitHub issue cited.
  • App Router switch is widely criticized: breaking changes, confusing mental model, more complexity for unclear benefit; some devs abandoned projects or stayed on Pages Router.
  • Configuration and “magic” under the hood make debugging and integrations (e.g., Sentry) harder; hydration errors and RSC complexity are recurring pain points.

Vendor Lock-in and Trust in Vercel

  • Many view Next.js as effectively a “dongle” for Vercel: nominally OSS, but design decisions nudge users toward Vercel hosting and serverless.
  • Concerns about “OSS-ish” behavior, marketing spin, and undisclosed employees defending Next.js in community discussions; this erodes trust for some architects.
  • Handling of the recent security vulnerability and Vercel’s ability to shield only its own customers before disclosure is seen as a structural conflict of interest.

SSR, Serverless, and Architecture Debate

  • Several argue SSR is overhyped: SEO crawlers execute JS, CDNs make static SPAs fast, and SSR adds huge complexity (especially serverless + headers-based tricks).
  • Others defend SSR for latency-sensitive users on bad connections and content-heavy pages, but agree it’s unnecessary for many apps.
  • Static export support is perceived as de‑prioritized over time, frustrating those using Next.js purely as a statically-exported SPA shell.

Alternatives and Simpler Approaches

  • Commonly suggested: React + Vite (often with a simple Express backend), Astro, React Router v7/Remix, TanStack Start, Nuxt, SvelteKit, Laravel, Django, or custom routers.
  • Some advocate going back to static hosting (“just copy files to a server”) plus a separate REST backend, or fully static SSGs with APIs.

Broader Ecosystem Concerns

  • Frustration with constant breaking changes in Next.js and React Router mirrors a broader complaint about JavaScript framework churn and renaming of old CS concepts.
  • Several express a preference for frameworks started by enthusiasts (Svelte, Vue) over corporate-driven ones, and scrutinize maintainers’ ethics when choosing stacks.