Islands Architecture
A mostly static HTML page where JavaScript wakes up only the interactive regions, not the whole screen.
What it is
Islands architecture sends a page as useful, mostly static HTML, then loads JavaScript for isolated interactive regions such as a search box, cart, or image carousel. Katie Sylor-Miller coined the name and Jason Miller's 2020 writeup spread it; Astro then made the pattern a headline feature: a component stays plain HTML unless a client directive such as 'client:visible' tells Astro to hydrate it.
Reach for it on content-heavy pages where most of the screen does not change after load. Each island can start on its own schedule, so a menu can become interactive immediately while a below-the-fold carousel waits until it enters the viewport. The result is less JavaScript and less hydration work than booting one application across the whole document.
The gotcha is coordination. Separate islands do not automatically share component context or in-memory state, and turning one giant app into twenty chatty islands can replace hydration cost with event plumbing. Keep shared state in the URL, server, browser storage, or a deliberately shared client store, and make the static HTML useful before any island wakes up.
Ask AI for it
Build this page with Astro islands architecture: render the article, navigation, and product details as static HTML; hydrate the search box with client:load, the cart with client:idle, and the reviews carousel with client:visible. Keep shared filters in URLSearchParams instead of component context, and verify that the main content and links still work with JavaScript disabled.