Astro: A Static Site Generator That Leaves the JavaScript Behind

Modern front-end development has a contradiction at its heart. Developers love the composability of component-based frameworks like React, Vue, and Svelte, but for content-heavy sites — blogs, marketing pages, documentation — shipping a full single-page application (SPA) is overkill. The result is often pages drowning in JavaScript that serve little purpose beyond rendering static text.

Astro, an open-source project led by the team at Skypack, aims to resolve that tension. Matthew Phillips, an engineer at Skypack and core contributor to Astro, joined the Smashing Podcast to explain how the project lets teams keep their familiar component workflows while producing plain, static HTML and CSS with JavaScript only where it's actually needed.

Bridging Two Build Philosophies

Phillips positions Astro as a halfway point between two camps. Traditional static site generators like 11ty rely on templating languages built for string concatenation; they're simple, but offer poor composability. On the other side are front-end driven generators like Gatsby, which bring the component model but carry the SPA weight. Astro borrows the developer experience and component syntax from modern frameworks, but generates static output by default.

Teams often end up building their marketing site or blog in React simply because that's what they already know. Switching to a different tool like Jekyll means pulling people out of their context and adding a second skill set to maintain. Astro's pitch is that teams can keep using the frameworks and workflow they already have, while the pages they ship are no heavier than they need to be.

Partial Hydration on Purpose

Astro's defining feature is that it ships no client-side JavaScript unless explicitly instructed to. Phillips says that was almost an accident: the team built the HTML generation part first and never wrote the code to load the scripts — and realised they liked the result better.

What followed is a technique called partial hydration, an idea Phillips credits to teammate Nate Moore's earlier work on a Preact project called Microsite. In a traditional SPA, a single root component wraps thousands of others; interactivity requires loading code for the entire tree. Astro instead encourages a page built from many small, independent "islands" of interactivity, each of which can be hydrated on its own terms.

Astro supports four hydration directives, and the developer must choose one explicitly for each interactive component:

  • load — runs when the browser fires its load event.
  • idle — schedules loading via the browser's requestIdleCallback API, when the CPU is free.
  • visible — loads only once the component scrolls into view.
  • media — loads only when a matching CSS media query applies, useful for mobile-only UI like slide-out sidebars.

This forces developers to pause and ask some useful questions about each component: does this need to run right away, or could it wait for the user to reach it? It's not magic — just a deliberate approach that makes performance a design consideration rather than an afterthought.

When a component does hydrate, the mechanism is straightforward. Astro injects a small script for that component to handle loading at the appropriate time, then imports the relevant JavaScript and hands rendering back to the framework's own client-side renderer. From there, a Vue component behaves exactly as a Vue developer would expect.

Framework Agnostic by Default

Astro achieves its framework-agnostic approach through plugins that act as adapters, knowing how to render each framework's components to HTML. The default npm install astro ships with React, Vue, Svelte, and Preact support, Phillips says. The team has also written plugins for Solid.js and LitElement. Writing a new one is straightforward, since each framework has its own mechanism for server-side rendering and the plugin simply needs to hook into it.

Rather than requiring sites to be built from scratch around Astro, Phillips notes that the architecture can be incrementally adopted. A team could drop an existing React app component into an Astro page with a client:load directive, effectively recreating a SPA, then begin extracting static pieces into Astro's own component format, .astro files, over time.

On the build tooling side, Astro leans on Snowpack, also developed by the Skypack team. Instead of compiling everything into one giant bundle during development, Snowpack acts as a dev server that translates each file on demand and serves it as native ES modules. Production builds are still fully bundled and optimised.

Markdown Components and the Road to 1.0

One eagerly awaited feature, which Phillips says is close to shipping, is the ability to use components inside markdown files. While Astro pages can already be written in .md format — common for blog posts — the upcoming .MDC extension will let authors embed components directly within their markdown content. That opens up useful possibilities for documentation sites, where an interactive example can be placed inline with explanatory prose.

Astro is still in pre-1.0 development, and while Phillips is reluctant to offer a hard date, he says the team is hoping to hit the milestone by the end of the year. A significant piece of that work is a rewrite of the Astro compiler from JavaScript to Go. This wasn't purely for its own sake; the team had known a rewrite was needed for architectural reasons, and the move offered the obvious bonus of faster build times.

Phillips is candid about Astro's maturity level. There are already plenty of production sites using it, particularly blogs and marketing sites, and starter templates covering blogs, multi-author blogs, portfolios, and documentation are available via npm init astro. But the project has so far deliberately steered clear of e-commerce, which he acknowledges will eventually require server-side dynamic rendering — a capability Astro does not yet possess.

An Accidental Project With Momentum

Astro's origin story is notably indirect. Skypack began as a CDN for loading JavaScript packages directly in the browser, and the team was looking for better ways to understand how developers built their sites so as to optimise those deliveries. The idea for a component-oriented tool grew out of that investigation, Phillips explains, and quickly took on a life of its own.

Astro's output can take advantage of Snowpack and the wider module ecosystem. Skypack integration remains an open possibility Phillips hopes to revisit — at deployment time, React imports might be rewritten to point at Skypack's CDN for better caching.

For developers debating whether to try a modern static site generator built for the component era, Phillips offers a simple endorsement: go download Astro. The project is actively developed by a core team of four at Skypack, supported by a passionate Discord community that includes specialists in each supported framework, ready to answer questions and fix issues around particular framework quirks.