Astro, Next.js, or Angular in 2026 — a decision tree that actually works

Three frameworks come up in almost every project conversation in 2026: Astro for content-heavy sites, Next.js for app-like UIs, Angular in the long tail of mid-sized businesses that have a decade of investment in it. They are all genuinely good. The interesting question is not which is “best” — it is which problem class each is built for.

Here is the decision tree I run through with clients, in roughly the order in which the questions matter.

1. Is this a content site or an app?

This is the single most useful question, and most teams skip it.

• Content site = mostly read-only pages, marketing, documentation, blog. JavaScript is the exception, not the rule. → Astro.
• App = users log in, do things, see state change without a page reload. → Next.js or Angular, depending on the next question.

If you are unsure, the test is: what fraction of pages would still be useful with JavaScript fully disabled? If the answer is “most of them”, you have a content site, and shipping a React or Angular runtime to every visitor is paying a tax for nothing.

2. Does an existing team already know one of these?

This is the second most important question and the most often ignored. A team that knows Angular will ship better software faster in Angular than in Next.js — even if Next.js is technically better for the use case. Existing skill compounds.

If the team is new and unbiased, the question becomes about hiring pool: in DACH, Angular and React/Next are both well-staffed. Astro is small but easy to pick up if you already know either.

3. What is the data layer doing?

• Mostly static, built from a CMS or markdown? → Astro shines, with optional server islands for interactive bits.
• Server-rendered with per-request data + auth (dashboards, e-commerce, admin tools)? → Next.js App Router is built for exactly this; the React Server Components model maps cleanly onto it.
• Long-lived, complex business app (insurance back office, ERP frontend, internal tool with 200 forms)? → Angular’s structure pays off here. Standalone components in v21 removed most of the historical pain points, and the long-term API stability matters more than novelty.

4. Are there hard performance constraints?

Astro ships almost no JavaScript by default, which means first-paint and Lighthouse scores are basically free. For a marketing site, this is a competitive advantage — German B2B buyers often check load times. For an app, the constraint is different: time-to-interactive matters more than first-paint, and Next.js’s streaming is more relevant.

5. The decision tree in code

function pickFramework(project) {
  if (project.mostlyContent) return 'Astro';
  if (project.teamKnows('Angular') && project.size === 'large') return 'Angular';
  if (project.needsSSR && project.hasComplexClientState) return 'Next.js';
  if (project.size === 'small' && project.team.openMinded) return 'Astro + React islands';
  return 'whatever the team will actually maintain';
}

The last branch is the one that matters most.

Things I deliberately did not put on the list

• SvelteKit, SolidStart, Qwik. All technically excellent. All with talent pools too small for most German SMBs to safely staff. I use them on personal projects, not on client work.
• Static site generators of yore (Hugo, Eleventy). Still great. Astro just covers the same ground and gives me React/Vue/Svelte islands when I need them.
• Plain Vite + React. A perfectly reasonable choice for a small app where Next.js’s machinery is overkill.

A note on changing your mind later

Migrations between these three are expensive but not catastrophic. The bigger cost is choosing one too early — before the team has clarity on what they are actually building. If in doubt, build the first vertical slice in Astro. If it grows into an app, you have lost a week and learned a lot. If it stays a content site, you have already shipped.