What you're choosing when a quote says Astro

It's a framework, not a platform you sign into

Start with the category, because that's where the confusion sits. Astro isn't a service with an account and a monthly bill. It's free, open-source software under the MIT licence. A developer writes files, a build step turns them into a website, and what you own is code that sits on almost any host.

There's no admin screen, and that's what catches people out. Nothing about choosing Astro gives your marketing lead somewhere to sign in and change a headline. That comes from connecting a content system, and it belongs in the quote rather than in month three.

The default that explains everything else

The standard way to build a website has been to build it like an application. The browser downloads a JavaScript framework, the framework draws the page, and the visitor waits. For an application that's a fair price. For a page that says the same thing to everyone, you've paid to ship a machine that assembles a document nobody was going to change.

Astro inverts the default. It runs the components once, ahead of time, and writes out ordinary HTML. Nothing has to run in the browser for the page to appear, because the page already exists. JavaScript is opt-in, one component at a time, and somebody has to ask for it by name.

Islands, and why one page can hold React and Svelte

The parts that do need to react are called islands, and the name carries meaning. A search box, a booking widget, a filter on a listing: each is a small piece of running code sitting in a page that's otherwise plain text. Each one decides when it loads: straight away, when the browser is idle, or when it scrolls into view. A calculator nobody scrolls to never costs anything.

Islands are separate, so they don't all have to be built the same way. Astro supports React, Preact, Vue, Svelte and Solid, and one page can hold more than one. Worth doing when you already own a component that works. As a habit it's a bad idea: two libraries mean two sets of conventions and two answers to a hiring question.

What it's actually good at

Content. Astro describes itself as a framework for content-driven websites, which is narrow for a self-description and also honest. Marketing sites, documentation, help centres, blogs. Anything where the value is words and pictures arriving quickly.

Markdown is a first-class input rather than something bolted on, and content sits in collections with a schema. An entry missing a required field breaks the build instead of publishing a page with a hole in it. That's a developer seeing an error rather than a customer seeing a blank.

Pages are fast, for the unglamorous reason that there's very little in them. Worth real money on a content site, and an advantage you hand straight back with four tracking scripts and a chat widget.

Where it stops

The ceiling isn't speed and it isn't size. It's interactivity that has to be shared.

Islands are independent by design, which is where the speed comes from and also where the limit is. Two islands on the same page don't know about each other. Making them agree, a sidebar filter redrawing the list beside it, means a shared store and wiring both ends into it. A dozen of those is a screen fighting the model it's built on.

The honest test is what proportion of a page changes because of the person looking at it. Near zero, and Astro is close to ideal. Most of it, and you're assembling by hand what an application framework gives you on day one.

None of that means it can't. Astro renders pages per request with a server adapter, and sites built on it do have signed-in areas. The question is whether you'd have picked it starting from the requirement rather than the website.

Who has to be around afterwards

This decides more builds than anything technical, and it almost never makes the proposal.

An Astro site is a codebase. Anything structural means a developer, a build step and somewhere to publish the result. What catches people out is the ordinary week: with no content system connected, changing a paragraph means editing a file in a repository. Fine for a technical team, a non-starter for most marketing departments.

The upkeep is dependency work rather than firefighting. Left alone for two years nothing stops working. The next change just costs more, because somebody updates two years of it first.

So settle two names before the platform: who publishes content here, and who updates the code. If the first one is a non-technical colleague, the content system isn't optional.