Curated inspiration sent every Tuesday
Unsubscribe at any time
Astro ships no JavaScript by default and asks you to opt in per component. Next.js ships a React runtime and asks you to opt out. For a content site — documentation, a blog, a marketing page — that default is the whole difference: an Astro page arrives as HTML and stays interactive only where you said so. For an application with state across the whole page, Next.js is the more natural fit, because you would end up hydrating most of an Astro page anyway and paying for the indirection.
A page renders to static HTML, and individual components are marked as interactive — islands in a sea of HTML. Each island hydrates on its own terms: immediately, when the browser is idle, when it scrolls into view, or only at a certain screen width. A page with a search box and an image carousel ships the JavaScript for those two things and nothing else. Server Islands, added in Astro 5, extend the same idea to the server: a cached static shell with holes that render per request.
Yes, and Vue, Svelte, Solid, Preact and Alpine, in the same project if you want. Astro renders them to HTML at build time and hydrates only the ones you mark as islands. In practice this matters most for migration — a team moving off Gatsby or a React site can bring its existing components rather than rewriting them. It also means Astro is rarely a lock-in decision in the way picking a single-framework tool is.
Astro 6 has been stable since March 2026. The dev server was rebuilt on Vite’s Environment API, so development runs your actual production runtime — fewer surprises deploying to Cloudflare Workers, Bun or Deno. It also brought Live Content Collections for externally hosted content, a built-in Fonts API, and a Content Security Policy API. The Content Layer and Server Islands that arrived in Astro 5 remain the structural features most projects are built around.
Applications. If most of a page is interactive state — a dashboard, an editor, anything behind a login where the whole view reacts to the user — the islands model works against you, and a framework designed for that is simpler. Next.js, Nuxt and SvelteKit all handle this better. Astro’s own positioning is content-driven sites, and it is unusually honest about where that stops.
Documentation teams, developer-tool companies, technical blogs, and agencies building marketing sites that need to score well on Core Web Vitals without a performance project. It has taken a large share of the work that used to go to Gatsby, which is no longer actively developed, and a good share of the content sites that defaulted to Next.js for no reason other than familiarity.
