Astro vs Next.js for content sites

For a content site — marketing pages, a blog, docs, anything where most pages are mostly static text — Astro ships less JavaScript to the browser by default, and that gap doesn’t close as the project grows the way you might expect. Next.js has gotten genuinely better about this with React Server Components, but the baseline mental model is still “this is a React app that happens to render some of itself on the server,” while Astro’s is “this is static HTML that happens to hydrate some of itself.” Those are different defaults, and defaults matter more than capability, because capability gets used inconsistently across a team while defaults get used everywhere.

The islands architecture is the concrete version of that difference. In Astro, a component doesn’t ship JavaScript to the client unless you explicitly mark it for hydration. In Next.js, the default direction has shifted toward server components too, but the ecosystem, the tutorials, and a lot of existing component libraries still nudge you toward 'use client' more often than the content actually needs, and that habit compounds across a real page.

Where I’d pick Next.js instead: if the site is genuinely more app than content — a dashboard, something with substantial client-side state, real-time updates, complex client-side routing between deeply interactive views. Next.js’s data-fetching and server-action patterns are built for that shape of problem, and Astro’s islands model starts to feel like you’re fighting the framework once more than a small fraction of the page needs to be interactive at once.

There’s also a team and ecosystem argument that’s not about either framework’s technical merits. If your team already knows React deeply and you need to move fast, Next.js’s larger ecosystem of components, patterns, and hires who already know it is a real advantage that no architecture diagram captures. I still default to Astro for content sites because most of what I build genuinely is content with a few interactive pieces layered on, not an application, and I’d rather the framework’s default match that shape than fight it. But “genuinely more app than content” is doing real work in that sentence, and it’s worth being honest with yourself about which one your project actually is before you pick.