Content-first by default, with islands for the interactive bits. Ships dramatically less JavaScript than React or Svelte for the same page — when the page is mostly content. The wrong tool for app-shaped products.
Pick Astro for docs sites, marketing sites, blogs, and any product that's mostly HTML with a few interactive components. It will out-perform Next.js or SvelteKit on Lighthouse for those use cases by a meaningful margin.
Astrois the default React framework in 2026 not because it’s the smallest or the simplest, but because it’s the one with the least friction across the widest set of problems — provided your problem is shaped like a React product on Vercel.
The bull case is straightforward. App Router, Server Components, and Server Actions collapse what used to be three layers (page, API route, client fetcher) into one mental model. The Vercel deploy story is unmatched — push to git, get a preview URL, promote on click. The ecosystem is the largest in React: every auth provider, every database client, every UI library has a first-class Astro example, and the AI assistants understand Astro better than they understand any other framework. For a team that’s already on React, choosing Astro means choosing the path with the most documentation, the most third-party integrations, and the most worked examples.
The bear case is also real. The cache model is the most complex in the ecosystem; newcomers fight it before they understand it, and “wait, is this server or client?” is a permanent confusion for the first month. Bundle size meaningfully exceeds Astro and SvelteKit — fine if you’re using RSC, pure overhead if you’re not. Lock-in is medium-strength: ISR-on-demand, image optimization, and middleware all bind tighter to Vercel-style hosts than to a generic Node server. Self-hosting works, but you trade deploy ergonomics for it.
For most product teams the calculus comes out in Astro’s favor, but the failure modes are specific and worth naming. If your app is a SPA, Vite + React Router ships less code. If your site is content-first, Astro is a better fit. If you need a pure backend, Hono or Fastify are the right answer. The honest summary: Astro is the right default, not the right answer in every case.
One row per dimension. The value is what Astrogives you; the note is the editorial framing — the quiet caveat that the marketing page won’t mention.
Three receipts at three traffic shapes. Numbers are illustrative — list-tier prices from May 2026, rounded to the dollar. Nothing here is invented; actual bills will vary with usage shape.
Six rows. The body describes how the feature works in 2026; the honest tradeoff is the part the docs won’t tell you. Skim the bold lines if you’re in a hurry.
The .astrofile format is HTML with a fenced JS section at the top for data fetching. Components run only at build/SSR time and emit HTML. They never hydrate, never ship JS. Used for everything that doesn’t need client-side state.
Server-only components keep the bundle empty by default. The downside: anything genuinely interactive must use a framework island (React/Vue/Svelte/Solid).
For interactive pieces, drop in a React/Vue/Svelte/Solid component and add a directive: client:load hydrates immediately, client:idle after the browser is idle, client:visible when scrolled into view, client:only skips SSR entirely.
Explicit hydration is the right model for content sites. Friction for app-shaped products where most of the page is interactive — at that point you'd reach for SvelteKit or Next.js anyway.
Define a Zod schema for your blog/docs frontmatter; getCollection() returns typed entries. Schema mismatches fail at astro build, not at runtime. The killer feature for long-lived content.
Best-in-class for Markdown sites. Overkill if your content is short-lived or non-Markdown — but at that point you're not the target audience.
Astro’s <ViewTransitions />uses the browser’s View Transitions API for smooth client-side navigation between static pages. SPA-feeling navigation without an SPA framework.
Genuinely smooth on supported browsers; falls back to full reloads gracefully where unsupported. Not a substitute for an SPA when state needs to persist across routes.
Astro routes can be .astro (HTML page) or .ts(API endpoint). Endpoints work like any other framework’s server routes — request handler, response object, body parsing.
Fine for forms, lightweight APIs, and the occasional dynamic route. Not the framework you'd choose to build a full backend in.
Adapters for Vercel, Cloudflare, Netlify, Node, Deno, and static. The static adapter (default) builds plain HTML/CSS/JS that deploys anywhere with a CDN — S3, GitHub Pages, Cloudflare R2, your own server. Genuinely portable.
Adapter coverage is broader than SvelteKit's; the static adapter is the headline since it's effectively zero-lock-in.
Six pitfalls visible in public docs and community discussion. None will stop you shipping; all of them will cost you an afternoon if you don’t know about them.
A client:only island doesn’t render on the server, so the user sees an empty space until JS loads. Use client:visible or client:idle instead unless you specifically need to skip SSR for an environment-dependent component.
Adding a required field to a content collection schema invalidates every existing entry that doesn't have it. The build fails, you backfill the field across N markdown files. Plan schema changes deliberately.
Astro’s built-in image optimization (<Image src=...>) requires the source image to be reachable at build time. Remote images need explicit image.domainsconfig, similar to Next.js’s remotePatterns. Surprising the first time.
Default output: 'static' means every route is prerendered. Adding an SSR route fails the build with a confusing error until you switch to output: 'server' or 'hybrid'. The mental model is opt-in dynamic, not opt-out static.
Two islands on the same page can't share state directly — each is hydrated independently. Use nanostores, or a tiny custom event bus, or accept that islands are isolated. Forgetting this leads to duplicated state.
By default, <ViewTransitions /> re-evaluates inline scripts on every navigation. Add data-astro-rerun to control this. Apps that mount once-only third-party widgets (analytics, intercom) often double-mount without this directive.
Three short framings. No clear-winner declarations — these are different bets, and the right pick is mostly a question of what you’re optimizing for. Linked comparison pages have the side-by-side detail.
Next.js is app-first — RSC, streaming, ISR, and middleware are designed for product surfaces with frequent state changes. Astro is content-first — islands, content collections, and zero-JS-by-default are designed for sites where most pages are mostly static.
Use Astro for the marketing site, the docs site, the blog. Use Next.js for the product itself. Many companies run both — Astro on the public surface, Next.js on /app. They're complementary, not substitutes.
SvelteKit ships less JS than Next.js but more than Astro. The frameworks overlap on small, performance-conscious content sites; SvelteKit is the right pick when you want one consistent reactive model end-to-end (every component is Svelte), Astro when you want zero JS for the static parts and to mix-and-match for the islands.
Pick Astro when 80% of the page is content. Pick SvelteKit when 80% of the page is interactive but you still want a smaller bundle than React.
Eleventy is the older, more minimal static-site generator. It's pure HTML output with template languages (Nunjucks, Liquid) — no component model, no islands. Great for static sites where you want the smallest possible toolchain.
Astro wins when you want to drop in a React or Svelte component for interactivity. Eleventy wins when you want zero framework runtime, period. Both are excellent at the static-first use case.