We switched from Next.js to Astro (and why it might interest you)

Original Article ↗ Hacker News Discussion ↗

Growing fatigue with the complexity and churn of modern JavaScript meta‑frameworks, especially Next.js, is pushing many developers to explore simpler options like Astro. Commenters highlight Astro’s strengths for content‑driven sites—fast static generation, excellent SEO, island‑based hydration, and framework‑agnostic components—contrasted with Next.js’s frequent breaking changes and heavy SSR/SPA machinery that feel disproportionate for low‑to‑medium complexity projects. Alongside praise for Astro, the conversation broadens into alternative approaches (Inertia.js, plain React with Vite, traditional full‑stack frameworks) and a wider concern that front‑end tooling changes too quickly to build durable expertise.

Overall sentiment

  • Strong theme of “complexity fatigue” with modern JS meta-frameworks, especially Next.js.
  • Astro is broadly perceived as simpler, more focused, and better aligned with content-heavy sites.
  • Significant skepticism about constant framework churn and breaking changes across the ecosystem.

Next.js: power vs pain

  • Many describe Next.js as powerful but overspecified and volatile:
    • App Router transition, caching, ISR, and SSR/CSR split are seen as hard to reason about.
    • Upgrades (e.g., 12→13, upcoming 15) are viewed as risky and work-heavy.
  • Some argue Next.js is “winning” (jobs, new projects, big brands), others say that’s marketing, not technical merit.
  • Complaints:
    • Difficult DX; feels like overkill for small or mostly-static sites.
    • Constant API and routing changes; docs and examples quickly go stale.
    • Perceived security “foot-guns” from mixing server and client code, though others counter it is safe by default.
  • A minority say they like modern Next (server components, forms, HATEOAS), and don’t share the doom-and-gloom.

Astro: strengths and limitations

  • Popular for:
    • Static site generation, blogs, marketing sites, content-focused projects.
    • “Islands” architecture: ship zero JS by default, then hydrate only interactive components.
    • Framework-agnostic components (React, Svelte, etc.) and good Markdown support.
  • Praised for:
    • Excellent documentation, stable behavior, and smooth upgrades.
    • Great performance and SEO “out of the box.”
    • Low barrier for both traditional HTML/CSS devs and React-heavy devs wanting something lighter.
  • Some use only its SSG features and ignore backend/server parts.
  • Minor criticisms:
    • Boundary between Astro components and framework components can be awkward.
    • Desire for a bit more built-in state/event handling without pulling in a full UI framework.

Alternatives and ecosystem fragmentation

  • Many mention moving away from Next.js to:
    • Astro, Vite + React, Inertia.js + “full-stack” frameworks, Svelte/SvelteKit, Nuxt, Solid, or even PHP/Rails-style stacks.
  • Remix’s merge into React Router is seen as adding to confusion.
  • Some advocate “just React” for apps and SSG/other tools for content; others push SSR + progressive enhancement (htmx, etc.).

Churn, stability, and philosophy

  • Widespread frustration that frontend knowledge decays quickly; frameworks rewrite themselves or are replaced within a few years.
  • Contrast drawn with more stable stacks (WordPress, traditional backends) and with static HTML/SSG approaches.
  • Some see frequent change as fashion-driven; others say iterative replacement by “something better” still has real value.