HTML first, interaction by exception
Astro is a server-first framework for content-driven websites. It renders page content as HTML and sends no client-side JavaScript by default; developers explicitly add browser code to components that need interaction.
An interactive component inside an otherwise static page is called an island. A navigation control, search interface, or other widget can hydrate independently while nearby headings, paragraphs, and links remain ordinary HTML.
| Page region | Initial delivery | Browser behavior |
|---|---|---|
| Static Astro content | Server-rendered HTML | No component runtime by default |
| Hydrated island | HTML plus selected component code | Activates independently |
| Multiple islands | HTML plus code selected for each island | Each island can use its own loading priority |
Hydration timing is explicit. client:load prioritizes an immediately needed control, client:idle defers work until the browser is idle, and client:visible waits until a component approaches the viewport.
Integrations and structured content
Astro can use React, Preact, Svelte, Vue, Solid, HTMX, web components, and other UI approaches for interactive regions. This allows selective reuse of familiar component systems without turning the complete document into one client-rendered application.
Useful ecosystem areas identified by the maintained repository include:
- UI integrations for React, Preact, Solid, Svelte, and Vue.
- Node runtime support and deployment adapters.
- Publishing tools such as MDX, RSS, and sitemap integrations.
- Script-related integration through Partytown.
Content collections organize and validate Markdown and related entries with TypeScript type safety. In practical terms, a team can define a consistent shape for articles or documentation, catch invalid content fields, and query a coherent collection instead of treating every file as unrelated.
Evidence versus implementation outcomes
Astro’s public documentation and maintained repository support claims about HTML-first rendering, opt-in hydration, supported UI approaches, and content collections. They describe framework capabilities and defaults, not the quality of every site built with Astro.
A finished project may still include large islands, several framework runtimes, heavy images, fonts, or third-party scripts. Those choices can affect performance and maintenance, so visitors should distinguish Astro’s documented model from results that require inspecting a particular implementation. The same distinction applies to accessibility and reliability: the framework supplies architectural tools, while the completed experience depends on how a team uses them.
