Astro islands in production: what we actually ship

Astro's whole pitch is that most of your site does not need JavaScript, and the parts that do can hydrate on their own. In practice, we have shipped enough Astro sites to know when this is a win and when it is just an idea.

When islands earn their keep

For anything that is 90% content (marketing sites, storefronts, journals) islands are a superpower. The header can be static, the hero can be static, the product grid can be static, and the one modal that opens a size chart can hydrate with client:visible. The rest of the page ships zero JS.

            // Only hydrate what actually needs it
<SizeChart client:visible />
<CartDrawer client:idle />
          

When they get in the way

The moment your page needs to share state across three islands, you are working against the model. Global state, cross-island events, and shared stores all become friction. That's a signal: it's usually a full SPA route, not an island.

If two islands need to talk, ask why they are not the same island.

Our rule of thumb

One island per interactive surface. If two surfaces need to coordinate, either merge them into one island or move the whole route to a framework page. Do not build islands that pretend to be a SPA, or you get the worst of both.