Astro ships zero JavaScript by default and lets you opt into interactivity per component. Next.js assumes a React application and gives you the ecosystem to build one. For content-led sites Astro is faster with less effort; for authenticated, stateful applications Next.js is the better fit and the gap widens as the app grows.
The one question
Is this a document that has some interactive parts, or an application that has some content pages?
Almost every project answers that immediately, and the answer settles the framework choice. A marketing site with a pricing calculator is a document with an interactive part. A dashboard with a blog attached is an application with content pages.
Get this backwards and you spend the project fighting the tool: either bolting a state layer onto something that resists it, or shipping a large runtime to render text.
Side by side
| Astro | Next.js | |
|---|---|---|
| Default JS to browser | None | React runtime |
| Interactivity model | Islands, opt in per component | Whole app is React |
| Content sites | Excellent | Fine, heavier |
| Authenticated apps | Workable, less natural | Excellent |
| Client-side routing | Optional | Built in |
| Shared client state | You wire it up | Native to the model |
| Ecosystem | Smaller | Very large |
| Mixed frameworks | React, Vue, Svelte, Preact together | React |
What islands actually change
The headline is “zero JavaScript by default,” which sounds like a benchmark talking point. The practical effect is different and more useful: interactivity becomes a decision you make deliberately, per component.
On this site the pages are HTML and CSS. A handful of components are interactive, and those are the only things that ship JavaScript. When I added a scroll-reveal system I had to consciously decide it was worth the bytes — the framework did not quietly absorb it into a runtime that was loading anyway.
That constraint is the value. It is not that Next cannot be fast; it obviously can. It is that Astro makes the expensive choice visible at the moment you make it, and visible costs get questioned.
The corollary: if nearly every component on your page needs to be interactive, islands stop helping. You have an application, and you are now hand-wiring what a React app gives you for free.
Where Astro surprised me
Two things I did not expect when I moved this site over.
It is not a static-site generator. With a server adapter you get real server rendering, API routes, and middleware, and you choose per page whether it prerenders. This site mixes both: the programmatic content pages prerender, while pages that read live data render per request. Treating Astro as a static tool undersells it badly.
Component-level framework choice is genuinely useful. Being able to drop a React component into an otherwise plain page, and only that component, meant reusing existing work without adopting React sitewide.
Where Next is clearly right
I would not build an authenticated product in Astro, and the reasons are specific rather than ideological.
Shared client state across routes is the big one. As soon as you have a signed-in user, a persistent nav that knows who they are, optimistic updates, and views reacting to the same store, you want the whole page to be one application. That is what Next is.
The ecosystem matters too. Auth libraries, data-fetching patterns, component kits, and the deployment story are all built assuming a React app. In Astro you can get there, but you are doing integration work that Next users are not.
And frankly the hiring and documentation surface is larger. That is a real engineering consideration even when it is not a technical one.
The honest middle
Plenty of projects sit between the two, and the usual answer is to split them.
Marketing site in Astro on the root domain, application in Next on a subdomain. Two deployments, two repositories, each using the tool that suits it. This is a common and sensible architecture, and the main cost is keeping the design system consistent across both.
What I would avoid is picking one to avoid running two things and then living with the mismatch for years. The overhead of a second deployment is a few hours. The overhead of the wrong framework is every sprint.
SEO and Core Web Vitals
Both render HTML on the server, so crawlability is not a differentiator — that argument is a few years out of date.
The real difference is interaction readiness. A page that ships no JavaScript is interactive when it paints. A page that hydrates a framework has a window where it looks ready and is not. That window is measurable and it is ranking-relevant.
Next can absolutely be fast, with server components and disciplined client boundaries. The difference is the default. On Astro you have to work to make a content page slow; on Next you have to work to keep one fast.
Worth stating plainly: framework choice is far from the biggest factor in either rankings or speed. A well-built Next site beats a badly-built Astro one comfortably.
How I choose now
- Content-led, mostly reading? Astro.
- Signed-in users with shared state? Next.
- Both, seriously? Two apps. Do not compromise on one.
- Small team, one thing to learn? Next, for the ecosystem, unless the project is genuinely a content site.
- Every component interactive? Islands are not buying you anything. Next.
FAQ
Is Astro better than Next.js?
For content-led sites, usually. For authenticated stateful applications, no — Next is the better fit and the gap grows with the app.
Can Astro handle server rendering?
Yes: server adapters, API routes, middleware, and per-page control over static versus server rendering.
Can you use React inside Astro?
Yes, per component. You opt into JavaScript only where it is needed rather than shipping a runtime for the whole page.
Which is better for SEO?
Both server-render, so crawling is fine either way. Astro tends to win Core Web Vitals on content pages because it ships far less JavaScript by default.
Related: other tool comparisons, how I built 58 pages on one Astro route, and how I build web apps.