Astro is a web framework created in 2021 that ships zero JavaScript to the browser by default. Pages are HTML. Components render to HTML. The browser receives HTML. This is considered a radical architectural decision in 2026, which tells you everything you need to know about the decade that preceded it.
“You’re telling me it just… sends HTML?”
— The Lizard, experiencing an emotion that might be approval“Just HTML.”
— The Astro documentation"…"
— The Lizard, nodding slowly
Origin
Astro was created by Fred K. Schott and the Astro team with a premise so simple it bordered on subversive: most web pages are content, most content is static, and static content does not require JavaScript. Therefore, the default should be zero JavaScript, and any JavaScript that ships should be an explicit, conscious choice.
This philosophy — send HTML unless you have a specific, defensible reason to send JavaScript — was considered obvious in 1996, radical in 2021, and is gradually becoming obvious again as the industry completes its twenty-year circumnavigation of the idea that browsers are, in fact, quite good at rendering HTML.
Islands Architecture
Astro’s defining architectural concept is islands: isolated interactive components embedded in a sea of static HTML.
A typical web page is mostly static. The header is static. The footer is static. The article text is static. The navigation is static. In a traditional React or Next.js application, all of this static content is nonetheless processed by JavaScript — parsed, hydrated, reconciled, diffed against a virtual DOM — despite the fact that it will never change, has never changed, and exists solely to be read by a human being who does not care about your component tree.
Astro renders the static parts as HTML at build time and leaves them alone. Only the genuinely interactive parts — a search widget, a comment form, a data visualisation — become “islands” that load their own JavaScript and hydrate independently. The rest of the page is HTML. Just HTML. The kind of HTML that loads instantly because there is nothing to parse, nothing to hydrate, nothing to reconcile.
“So the page is HTML, and the interactive bits are islands of JavaScript in a sea of HTML.”
— A newcomer, understanding the concept“In 1996 we called this ‘a website with a few scripts.’”
— The Lizard, who is technically correct
The islands hydrate independently, which means a slow-loading comment widget does not block the rendering of the article above it. This is the kind of obvious, sensible behaviour that required a named architectural pattern because the JavaScript ecosystem had spent so long doing the opposite that “don’t block the whole page” needed to be presented as an innovation.
Framework Agnosticism
Astro components can be written in Astro’s own .astro syntax (which resembles HTML with a frontmatter script block), or they can use React, Vue, Svelte, Solid, Lit, or Alpine. You can mix frameworks in the same page. A React island can sit next to a Svelte island on a page of static Astro HTML.
This is either a triumph of interoperability or a symptom of an ecosystem so fragmented that a framework’s selling point is “you don’t have to choose.” Both readings are correct.
In practice, it means teams can adopt Astro without rewriting their existing components. The React team keeps their React components. The Svelte enthusiast keeps their Svelte components. The components render to HTML at build time (or to islands at load time), and Astro doesn’t care which framework produced them, because by the time the HTML reaches the browser, the framework is irrelevant.
The Lizard approves of things that become irrelevant before reaching the browser.
Content Collections
Astro has first-class support for content authored in Markdown and MDX, with typed frontmatter schemas, automatic slug generation, and a query API for filtering and sorting content. You put Markdown files in a directory. You define a schema for the frontmatter. Astro indexes them and provides a typed API for querying them.
A developer recognised this pattern immediately, because that developer built this pattern. lg indexes Markdown files from a directory, parses frontmatter, builds a queryable index, and renders HTML. Astro’s Content Collections do the same thing with different technology and better documentation.
The recognition was not uncomfortable. It was the quiet satisfaction of seeing your own architectural instincts validated by a framework with actual funding and a documentation team. The Markdown-in, HTML-out pipeline is correct. It was correct when lg was built. It was correct when Astro was built. It has been correct since the first static site generator, which was called cat *.html > index.html and ran in 1994.
“They reinvented what I built. But they did it properly, with TypeScript schemas and a logo.”
— A developer, without bitterness
The HTMX Alignment
Astro and HTMX occupy adjacent philosophical positions: HTML is the product, not the build artifact. The server’s job is to produce HTML. The browser’s job is to render HTML. The framework’s job — if a framework is even necessary — is to get out of the way as quickly as possible.
Where they differ is scope. HTMX extends HTML with attributes that let the server send HTML fragments in response to user interactions. It requires no build step, no bundler, no framework. Astro is a full build-time framework that compiles components into static HTML and optionally hydrates interactive islands. HTMX is “HTML with superpowers.” Astro is “a build system that outputs HTML and not much else.”
Both arrive at the same destination: the browser receives HTML, the page loads fast, and the Lighthouse score is a number that makes the performance team stop sending passive-aggressive Slack messages.
This article, like the others in this series, was delayed slightly by the editorial workstation’s reluctance to perform basic tasks at reasonable speed. Investigation revealed that the machine’s 16 GB of RAM had been colonised by Electron-based applications — a chat client, a code editor, a note-taking app, and a music player, each running its own instance of Chromium — leaving approximately 900 MB for the actual browser doing the actual research. The irony of writing about frameworks that ship zero JavaScript on a machine drowning in JavaScript applications was noted and filed under “recurring themes.”
riclib’s Position
A developer would use Astro for a content-heavy site that needed more interactivity than raw HTMX could provide. A marketing site with interactive demos. A documentation site with live code playgrounds. A blog with embedded data visualisations. These are the cases where “just send HTML” covers 90% of the page and the remaining 10% needs real client-side JavaScript, and Astro’s islands architecture lets you serve that 10% without punishing the other 90%.
It is the closest any modern framework comes to the Boring Technology stack: Markdown in, HTML out, JavaScript only where necessary, build step that produces files a 1998 web server could host without modification.
“But what if we also added—”
— The Caffeinated Squirrel, reaching for the keyboard“No.”
— The Lizard"—just a small interactive—"
— The Caffeinated Squirrel“That is what the island is for. One island. The rest is HTML. Close the terminal.”
— The Lizard, who has seen what happens when the islands multiply
What Astro Is Not
Astro is not the right choice for a highly interactive application — a real-time dashboard, a collaborative editor, a game. These are applications where the majority of the page is JavaScript by necessity, and Astro’s “zero JS by default” philosophy becomes a hindrance rather than a feature. For those cases, Svelte or React (possibly via Next.js, if you have accepted Zawinski’s Law into your life) are more appropriate.
Astro is for the other 80% of the web: the pages that are mostly content, mostly static, mostly read and not interacted with. The pages that the industry over-engineered for a decade by wrapping them in JavaScript frameworks that loaded 200 KB of runtime to display text that had not changed since it was written.
For those pages, Astro does what the browser has always wanted: it sends HTML and gets out of the way.
Measured Characteristics
| Metric | Value |
|---|---|
| JavaScript shipped by default | 0 KB |
| Frameworks usable as island sources | 6+ (React, Vue, Svelte, Solid, Lit, Alpine) |
| Content Collections schema validation | TypeScript-native |
| Lighthouse score (content pages) | 100 (achievable, common) |
| Philosophical alignment with HTMX | ~85% |
| Philosophical alignment with The Lizard | ~72% (deductions for requiring Node.js) |
| Pages on the web that are mostly static content | ~80% |
| Pages on the web wrapped in unnecessary JS frameworks | ~80% (same pages) |
| Electron processes that delayed this article | 4 (RAM: 3.1 GB, purpose: unclear) |
| Time since “just send HTML” was a radical idea | 0 years (it is 2026 and it is still radical) |
| The Lizard’s approval rating | Almost nods. Almost. |
See Also
- HTMX — The other “just send HTML” philosophy, no build step required
- React — The framework Astro lets you use sparingly, as a treat
- Svelte — Another compiler-first framework, shares the “less JavaScript” instinct
- Next.js — What happens when you go the other direction (more of everything)
- JavaScript — The language Astro tries very hard not to ship
- HTML — The technology that was sufficient all along
- Boring Technology — The philosophy Astro embodies
- lg — A Markdown-to-queryable-index pipeline that preceded Content Collections by several years
- The Lizard — Almost approved. This is the highest rating available.
