Software & Dev 4 min read
Astro vs. Next.js: How to Actually Choose
Two excellent frameworks with genuinely different philosophies. A practical, no-hype guide to picking the right one — and the single question that settles it.
The short version: Astro if your site is mostly content, Next.js if your site is mostly application. That one-liner is right often enough to be useful, and wrong often enough to be worth unpacking.
They’re answering different questions
This is the part most comparisons skip. These frameworks disagree at the level of philosophy, not features.
Astro starts from zero JavaScript. A page is HTML by default. Interactivity is opt-in, component by component — the “islands” model. Its central question is how little can we send?
Next.js starts from a React application. You get the full component model everywhere, with Server Components trimming what reaches the browser. Its central question is how do we make a large app fast?
Neither is a workaround for the other. They’re different answers to different problems.
| Astro | Next.js | |
|---|---|---|
| Default output | Static HTML | React app (server + client) |
| JS you ship | Only what you opt into | A framework baseline, then your code |
| Sweet spot | Blogs, docs, marketing, storefronts | Dashboards, SaaS, authed apps |
| Interactivity | Islands, any framework | React, everywhere |
| Learning curve | Gentle — it’s mostly HTML | Steeper — RSC, caching, routing |
| Escape hatch | Add React/Vue/Svelte islands | Drop to static export |
When Astro is the obvious answer
If the content is the product — a blog, documentation, a marketing site — Astro is hard to beat. Pages are fast because there’s less to download, and you cannot out-optimise JavaScript you never sent.
The underrated feature is content collections: typed, schema-validated frontmatter that fails at build time. If your content has structure, the framework enforces it instead of you hoping.
The other underrated part: React and Vue and Svelte islands can coexist on one page. Astro genuinely doesn’t care.
When Next.js is the obvious answer
The moment your project becomes an application — real auth, dashboards, live data, deeply stateful UI, optimistic updates — Next.js starts paying for itself. You can build these in Astro, but you’ll reach for React islands so constantly that you’re paying Astro’s constraints for none of Astro’s benefit.
The ecosystem matters too. For anything involved, the library you need probably assumes React and probably ships a Next.js guide.
The question that settles it
Forget benchmarks. Ask this:
What proportion of my pages need to be interactive to be useful at all?
- Under ~20% — a content site with some widgets. Astro.
- Over ~60% — an app with some marketing pages. Next.js.
- In between — either will work, so pick on team familiarity. That’s a real engineering criterion, not a cop-out: a team fluent in React shipping Next.js will beat the same team learning Astro under a deadline.
Two mistakes worth avoiding
Overestimating how much “app” you’re building. Easily the most common. Teams pick the heavier tool for interactivity they imagine they’ll need, ship a content site on an app framework, and pay for it on every page load forever.
Picking Astro and then fighting it. If you’ve wrapped the whole page in one giant island, you chose wrong. That isn’t Astro failing — it’s a signal you’re building an app.
The honest answer
Both are genuinely good, and this isn’t a fight where one wins. Choose on the ratio of content to interactivity, be realistic about which one you’re actually building, and remember that the JavaScript you don’t ship is the only JavaScript guaranteed to be fast.
When in doubt, start lean. It’s far easier to add an island than to remove a framework.