Next.js is infuriating

Original Article ↗ Hacker News Discussion ↗

Logging and observability pain points

  • Many agree with the article that just getting logs out of a production Next.js app—especially via middleware—is far harder than in typical back-end frameworks.
  • Debate centers on what “production-quality logging” means: some say stdout + a basic logger is fine; others insist it must include telemetry, rotation, structured logs, and integration with systems like Kibana/Datadog.
  • Next.js’s answer (OpenTelemetry + instrumentation.ts) is seen by critics as overkill and “one more heavy layer” when developers just want logger.info() to work; defenders argue OTEL is a sensible, vendor-neutral standard for distributed systems.
  • Several reports say OTEL + Pino in Next is brittle (dependency flags, import order, globals, experimental packages), reinforcing the sense that observability is a “two-problem” situation now.

Middleware, runtimes, and mental model confusion

  • A central complaint: Next.js “middleware” doesn’t behave like middleware in Express/Rails/Rack-style stacks. It’s a single edge hook, not a composable chain on the main server.
  • Official guidance to “combine multiple middlewares into one file” feels fundamentally wrong to those expecting conventional, pluggable middleware.
  • The edge vs Node vs SSR vs client execution model (plus React Server Components, streaming, and caching) is widely described as hard to reason about; people struggle to know where code runs and when.
  • Some say the article misunderstands these boundaries; others respond that if a seasoned dev can’t form a clear mental model, that’s a framework design failure, not “user error.”

Complexity, churn, and documentation

  • Many recall Next.js (with the Pages Router) as simple and effective; the App Router + RSC era is seen as a turning point into “resume‑driven” over‑engineering.
  • Frequent major versions, API shifts, and partially baked features (middleware, app router, RSC) create upgrade fear and make AI-generated examples unreliable.
  • Documentation is criticized as high-level and marketing-friendly, but thin on precise execution details, pitfalls, and non‑Vercel deployment nuances.

Vercel, lock-in, and motivations

  • Strong sentiment that Next.js’s rough edges (edge-only middleware, lack of simple logging, awkward self-hosting, image stack quirks) funnel teams toward Vercel’s platform.
  • Some frame this as deliberate vendor lock-in and “enshittification”; others counter that Vercel legitimately funds OSS and provides good DX, and that self-hosting Next is possible (e.g., via Docker/Kubernetes).
  • There’s broader worry that React’s official endorsement of Next has effectively “captured” the React ecosystem for a single commercial actor.

Comparisons and alternatives

  • Multiple people state they’ve migrated away from Next to:
    • React Router v7 / “framework mode” (ex‑Remix)
    • Vite + React + explicit API servers
    • Astro (SSG + islands)
    • SvelteKit, Nuxt, SolidStart, Hono/HonoX, Fresh (Deno)
    • Inertia.js with Laravel/Rails/Adonis, or plain Django/Rails/Laravel + HTMX/Alpine/Datastar
  • Many praise these for simpler mental models, explicit server/client separation, or more conventional middleware and logging stories.

Broader ecosystem criticism

  • Thread repeatedly zooms out to critique modern JS/TS and “full-stack React” culture: too many layers, fast-breaking APIs, marketing-driven design, and frameworks optimized for e‑commerce/landing pages rather than complex apps.
  • Several back-end and veteran web devs say they’re retreating to “boring tech” (Rails, Django, Spring, Phoenix, Go, plain HTML+CSS+minimal JS) for long‑lived, maintainable systems.