astro.build

What is Astro?

Astro is an open-source web framework for building content-driven websites. It renders page content as HTML and sends no client-side JavaScript by default, while allowing developers to add independently hydrated components where browser interaction is necessary.

This approach suits blogs, documentation, marketing sites, portfolios, landing pages, community sites, and content-led e-commerce experiences. Astro can incorporate several familiar UI frameworks without requiring the entire page to become a client-rendered application.

Quick summary

• Primary purpose: Build content-driven websites around server-rendered HTML.
• Default browser cost: No client-side JavaScript unless the project explicitly adds it.
• Core architecture: Interactive components become isolated islands inside otherwise static pages.
• Supported UI approaches: React, Preact, Svelte, Vue, Solid, HTMX, web components, and others.
• Content tooling: Content collections organize and validate Markdown with TypeScript type safety.
• Best fit: Sites where reading and navigating content matter more than continuous browser-side state.
• Main tradeoff: Teams must decide which components need JavaScript and when they should load.

What problem does Astro try to solve?

Content websites often use application-oriented frontend architectures even when their pages mainly contain headings, articles, product explanations, images, and links. This can send JavaScript for a broad component tree despite much of the page needing no browser execution.

Astro begins from a server-first assumption: content becomes HTML, and browser execution is added only where interaction requires it. The delivery model can therefore follow the page's actual behavior instead of treating every element as part of one interactive application.

The official documentation describes Astro as content-driven, server-first, fast by default, easy to use, and developer-focused. These are design goals rather than guarantees, because images, third-party scripts, component code, and implementation choices still affect the finished site.

What Astro organizes for a content project

• Pages whose main value is readable HTML.
• Reusable layouts and components around that content.
• Markdown content organized through collections.
• Validation and TypeScript-aware schemas for collection entries.
• Optional interactive components using supported UI frameworks.
• Integrations added according to content and delivery needs.

How does Astro render a page?

Astro separates static page content from interactive browser components. The server produces HTML, while components marked for hydration receive JavaScript and become interactive according to a directive selected by the developer.

This differs from making the complete page one client-side component tree and from publishing a completely static document that cannot add browser behavior. Astro occupies the middle ground by assigning interaction to specific parts of a page.

Architecture and rendering comparison

Page region or approach	Initial output	Browser JavaScript	Interaction boundary	Practical implication
Static Astro content	Server-rendered HTML	None by default	No hydrated component	Text, links, and other static content remain useful without a component runtime.
Astro interactive island	HTML plus an explicitly hydrated component	Loaded for that component	The individual island	A menu or search control can become interactive without hydrating the surrounding article.
Several Astro islands	HTML plus separately hydrated components	Loaded according to each island's needs	Each island hydrates independently	Teams can prioritize important interaction and defer components that are not immediately needed.
Whole-page client application	Application-specific shell or HTML	Commonly supports a broad client component tree	Much of the page shares browser-side execution	This can suit continuous interaction but may apply an application model to content that does not need one.

These boundaries do not guarantee a particular performance result. A large island can still send substantial code, while heavy media and unrelated scripts can slow the page; Astro supplies a low-JavaScript default, but the finished experience remains the team's responsibility.

What is an Astro island?

An island is an interactive UI component within an otherwise static page. Surrounding headings, paragraphs, links, and other non-interactive material remain HTML, while the island receives the browser code required for its behavior.

Islands hydrate independently, so activating one component does not require every other interactive component to activate with it. Supported component frameworks can coexist, although using several may increase runtime duplication and maintenance demands.

When can an island hydrate?

• client:load: Prioritizes the component when the page loads.
• client:idle: Defers hydration until the browser has idle time.
• client:visible: Waits until the component approaches the viewport.

These directives make loading priority part of component placement. A control needed immediately can be handled differently from an interactive element farther down the page, and the choice should follow user need rather than a blanket rule.

What islands do and do not guarantee

Islands help a team do this	Islands do not guarantee this
Keep static content as HTML	Every completed page will be fast
Add JavaScript only to selected components	Hydrated components will be small
Give islands different loading priorities	Third-party scripts will be efficient
Use supported UI frameworks for interactive regions	Mixing frameworks will have no runtime or maintenance cost
Preserve a content-first page structure	Images, fonts, and other assets will be optimized automatically

The useful property is control. Hydration remains visible in component usage, allowing developers to review where JavaScript enters the page and whether each dependency earns its cost.

How does Astro handle UI frameworks and content?

Astro supports React, Preact, Svelte, Vue, Solid, HTMX, web components, and other UI approaches. A team can use a familiar component framework for an island while keeping the surrounding document within Astro's server-rendered page model.

This flexibility can support gradual adoption or preserve an existing component investment, but it does not make combining every framework beneficial. A consistent primary approach is usually easier to understand, and each additional runtime should solve a specific problem.

Content collections complement this rendering model by giving Markdown and related content an organized, validated structure with TypeScript type safety. A publication or documentation project can treat its content as a coherent dataset rather than unrelated files.

Maintained ecosystem areas

The framework repository identifies officially maintained packages for several needs:

• UI integrations for React, Preact, Solid, Svelte, and Vue.
• Runtime support through the Node integration and several deployment adapters.
• Content and publishing tools including MDX, RSS, and sitemap integrations.
• Script-related integration through Partytown.

Projects can begin with Astro and add integrations when requirements justify them. Current documentation and maintained package information should guide installation choices because availability and compatibility can change.

Who is Astro a good fit for?

Astro is best aligned with projects where content should be available as HTML and interaction occupies distinct regions. It is especially worth evaluating when the principal user activity is reading, browsing, comparing, or discovering information.

An application-like product can still contain content-first pages, but its dominant interaction model matters. If most screens depend on shared client state and continuous browser updates, island boundaries may provide less value or require more architectural decisions.

Fit and not-fit guidance

Astro is worth considering when	Evaluate other approaches carefully when
The project is a blog, documentation site, portfolio, landing page, marketing site, community site, or content-led commerce experience.	Most screens behave as a continuously interactive browser application.
Important content should arrive as HTML without waiting for a client runtime.	Nearly every page region requires hydration and shared browser-side state.
Interactivity can be divided into clear components.	Interaction is difficult to separate into independent regions.
The team wants to reuse supported UI components selectively.	The team expects framework mixing to be effortless or cost-free.
Markdown organization, validation, and type safety are valuable.	The project has little content and gains no meaningful benefit from content collections.

This guidance is an architectural filter rather than a verdict. The strongest evaluation uses one representative page containing real content and the most demanding interaction expected in production.

What are Astro's main tradeoffs?

Astro's primary advantage and design burden come from the same choice: browser JavaScript is selective. Teams gain control over hydration but must define sensible component boundaries and loading priorities.

Benefits supported by the architecture

• Static content remains server-rendered HTML.
• JavaScript is opt-in for components that need browser behavior.
• Islands can hydrate independently.
• Loading priority can reflect when an interaction becomes useful.
• Supported UI frameworks can be used without controlling the complete page.
• Content collections provide organization, validation, and TypeScript type safety.

Costs and decisions to account for

• Developers must identify which components genuinely require hydration.
• Poorly chosen directives can load code earlier or later than users need it.
• Large islands can weaken the benefit of selective hydration.
• Several UI frameworks can introduce duplicate runtime code and extra maintenance.
• Third-party scripts and oversized media remain performance concerns.
• Interaction-heavy products must determine whether islands match their state model.

Astro favors deliberate composition. It removes automatic client-side JavaScript from the starting point but does not remove the need to review dependencies, assets, accessibility, or actual page behavior.

How should a team evaluate Astro?

A useful evaluation should reproduce the project's hardest content and interaction requirements. A minimal demonstration may prove that Astro runs, but it cannot show whether the architecture fits the real authoring workflow or browser behavior.

Evaluation checklist

1. Choose a representative page. Use real headings, body content, navigation, images, and links rather than placeholders.
2. Identify static regions. Mark which parts can remain HTML without a browser-side component runtime.
3. Select the hardest interaction. Include the most demanding component reasonably expected.
4. Define island boundaries. Determine whether interactive regions can hydrate independently without awkward state coordination.
5. Assign hydration priorities. Test whether client:load, client:idle, or client:visible matches when each component becomes useful.
6. Review framework usage. Confirm that every UI integration solves a concrete need and note duplicated runtime costs.
7. Test the content model. Create a representative collection and verify that validation and TypeScript types support the editorial workflow.
8. Inspect delivered output. Confirm that essential content is present as HTML and identify JavaScript added by hydrated components.
9. Exercise real constraints. Include expected media, third-party scripts, navigation, and deployment requirements.
10. Compare maintainability. Ask whether the content-and-interaction boundary is clear to the team operating the site.

The decision should rest on that prototype. Documented defaults explain Astro's intent, while a representative implementation reveals whether they match the project's actual content, interaction, and maintenance needs.

How did Astro begin, and how is it governed?

Astro was publicly introduced in June 2021 through an official post authored by Fred Schott and Nate Moore. The source identifies both as the authors who introduced the project and does not support assigning either person a sole-founder label.

An official 2025 governance announcement named Astro's Technical Steering Committee. At that observation date, it identified Matt Kane as framework team lead and Sarah Rainsberger as documentation team lead; these are dated facts because leadership and committee membership can change.

Project and community facts

• June 2021: Fred Schott and Nate Moore authored Astro's official introduction.
• 2025: Astro announced its Technical Steering Committee and dated team roles.
• License: The maintained framework repository identifies Astro as free and open-source software under the MIT license.
• Support: Current official release material directs help and feedback to Astro's Discord community.
• Participation: The project directs contributors and project participation to GitHub.
• Getting started: The maintained README recommends npm create astro@latest; manual installation uses npm install astro.

Governance explains how the open-source project organizes responsibility, while rendering, content tools, and interaction boundaries determine its technical fit.

What does astro.build represent?

astro.build is Astro's official website, while Astro the framework is the subject described here. The maintained website repository states that the site is built with Astro, making it a relevant first-party example without making its maintenance details part of the framework's definition.

The maintained framework repository is the stronger reference for supported packages, installation paths, licensing, community, and contribution information. Astro's documentation remains the primary reference for its server-first model, content focus, islands architecture, and hydration directives.

Bottom line

Astro's proposition is clear: render content as HTML, then add browser JavaScript only to components that need interaction. It is compelling for content-driven sites with separable interactive regions and less obvious for products whose interfaces depend on continuous client-side state.

Do not assume that the default makes every implementation fast. Build a realistic page, inspect its HTML and hydrated components, test the content workflow, and confirm that island boundaries remain understandable as the project grows.