Astro or SvelteKit, how I decide which to use

With Astro and SvelteKit both already at version 1.0, I’ve been using them side by side for months, depending on the project. People ask me quite often which one “is better,” and the honest answer is that I stopped asking myself that question — I ask a different one.

The question I actually ask

How much genuine interactivity does this page need? Not how much JavaScript it has, but how much shared state, how much client-side logic that reacts to what the user does in real time.

If the answer is “not much” — a blog, a landing page, a client’s site with four sections and a contact form — Astro wins without discussion. Its islands model ships zero JavaScript by default and only hydrates the specific components that actually need it. For content that’s read more than manipulated, it’s exactly what’s needed and not a byte more.

If the answer is “a lot” — a panel with filters that update on the fly, forms with complex reactive validation, anything that feels more like an “app” than a “page” — that’s where I reach for SvelteKit from the start. You can build an app like that in Astro by layering a UI framework on top, but then I’m paying the complexity of two different mental models in the same project.

A real case

This very site is SvelteKit, even though under the hood it’s almost entirely static content — a blog and a handful of pages. It could just as easily have been Astro. I chose it because I already knew that at some point I’d want components with more interaction (blog filters, forms, a calendar) and preferred not to have to migrate frameworks halfway through. For a project I know for certain will stay pure content, I do reach for Astro.

What they have in common that I like about both

Both take performance seriously by default, not as an option you have to switch on. And both have made me feel like I’m writing less boilerplate than with anything else I’ve used before — which, coming from Angular, is saying something.