Most JavaScript frameworks started in the browser and later learned to render on the server. Astro started from the other end. A page is HTML produced at build time or on request, and interactivity is something you add to individual components, not something every page pays for. That one decision explains most of how Astro feels to work with.
Content-driven sites
Astro is designed for sites where most of the page is content: documentation, blogs, marketing pages, portfolios, knowledge bases, and storefront catalog pages. These pages are read far more often than they are interacted with, so the cost that matters is how fast the HTML arrives and how little script the browser has to parse before the reader can use it.
This knowledgebase is an Astro site. Every article you read here is a Markdown file that Astro turns into static HTML during astro build. The search box and the diagrams load their own scripts; the rest of the page ships no framework runtime at all.
Zero JavaScript by default
An Astro component renders to HTML on the server and then disappears. There is no virtual DOM in the browser and no hydration of the page as a whole. If a component needs no interactivity, the reader receives markup and CSS only.
You can still use React, Vue, Svelte, Solid, or Preact components. They render to HTML on the server like everything else. Only when you add a client:* directive does Astro send that component’s JavaScript and hydrate it in the browser.
---import Header from '../components/Header.astro';import SearchBox from '../components/SearchBox.jsx';---<Header /><SearchBox client:idle />Header becomes plain HTML. SearchBox becomes HTML plus a small bundle that hydrates once the browser is idle.
Islands architecture
The pattern behind this is called islands architecture. Katie Sylor-Miller described it at Etsy, and Jason Miller popularized the name in 2020. The page is a static sea of HTML; interactive components are islands inside it, each hydrated on its own schedule and independent of the others.
flowchart TB
subgraph page [Server-rendered HTML page]
nav[Navigation - static HTML]
article[Article body - static HTML]
search["Search island - client:idle"]
chart["Chart island - client:visible"]
footer[Footer - static HTML]
endBecause islands are independent, a slow chart does not delay the search box, and a component below the fold can wait until it scrolls into view. Astro also supports server islands: components rendered on the server after the rest of the page, which lets a static page include a personalized or frequently changing fragment. Both kinds are covered in Islands and client directives.
Static first, server when needed
By default Astro builds every route to a static file. Hosting is then a matter of uploading the dist/ folder. When a route needs request data such as cookies, a form post, or a database read per visitor, you opt that route into on-demand rendering and add an adapter for your host. A single project can mix both: static articles alongside a server-rendered account page.
Server rendering in Astro covers adapters, middleware, and actions.
How Astro got here
Fred K. Schott and the team behind the Snowpack build tool started Astro in 2021. The milestones below explain features you will meet in the rest of this series:
| Release | Year | What it introduced |
|---|---|---|
| Astro 1.0 | 2022 | Stable .astro components, islands, integrations |
| Astro 2 | 2023 | Content collections with schema validation |
| Astro 3 | 2023 | View transitions, built-in image optimization |
| Astro 4 | 2023 | Dev toolbar, internationalized routing |
| Astro 5 | 2024 | Content Layer with loaders, server islands, static and hybrid merged |
| Astro 6 and 7 | 2026 | Current majors; this site runs Astro 7 |
In January 2026 the Astro team joined Cloudflare. Astro remains MIT-licensed and deploys to any host, not only Cloudflare.
When to choose something else
Astro is a weaker fit when most of the product is one long-lived interactive surface: a design tool, a dashboard where every panel updates live, or an editor. There the page is effectively one large island, and a client-first framework such as Next.js, Remix, or a plain React single-page app gives you routing and state management that assume the browser is in charge.
A practical test: if you can describe the page as “content with a few interactive widgets”, Astro is likely the simpler tool. If you describe it as “an application that happens to have a landing page”, start elsewhere, and consider Astro for the landing page.
Next: Creating an Astro project.
Check your understanding
Question 1 of 6
0 of 6 checked