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

Original Article ↗ Hacker News Discussion ↗

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.