Why Astro Ships Zero JavaScript by Default

Most front end frameworks treat JavaScript as the starting point. Astro treats it as an opt-in. Every component you write in an Astro project is rendered to plain HTML and CSS, and the client side JavaScript that would normally ship with that component is stripped out unless you ask for it by name. There is no build flag to hunt down and no hope that a bundler might shake the code away later. The default output of an Astro build is a site with no component JavaScript at all.

That rule is not a performance trick bolted on at the end. It came from the project's origin story. Astro was created by Fred K. Schott, who had already spent years inside the JavaScript build tooling world as the author of Snowpack, an early unbundled development server. He watched teams adopt React or Vue for a mostly static marketing site and then pay for it on every page load: a framework runtime, a hydration pass, and a bundle that grew with every component added. Astro 1.0, published on August 9, 2022, packaged the opposite bet. Write components in whatever syntax you like, but let the server produce HTML and only wake up the parts that actually need a browser.

The idea behind that pattern is the island. Astro's documentation credits the term component island to Etsy's front end architect Katie Sylor-Miller, who used it in 2019, and to Jason Miller, who documented and popularized the concept in his 2020 essay on islands architecture. The mental model is a page as a mostly static document with a few small, self contained pockets of interactivity floating in it. Everything around an island is inert HTML. Inside an island, a client framework runs, hydrates, and manages state. The savings are real because hydration is the expensive part: parsing a framework runtime, walking the tree, attaching listeners, and rebuilding component state in the browser.

In Astro the boundary between the two is a directive on the component tag. Writing client:load means hydrate this island as soon as the page loads. client:idle waits for the browser to be free, client:visible defers work until the island scrolls into view, client:media ties hydration to a media query, and client:only skips server rendering entirely. Because the choice lives at the call site, a senior developer can make the tradeoff per component instead of per application. A search box on a documentation page, arguably, needs client:idle. A newsletter form below the fold needs client:visible. A static price table needs nothing at all, and in Astro nothing is exactly what it gets.

What this buys you in practice is a clean separation between content and interface machinery. Content driven sites, documentation portals, blogs, marketing pages, and catalogues are dominated by markup that never changes after render. Shipping a runtime to draw them is pure overhead. When I audit a slow content site, the profile is usually grim: main thread time spent on hydration, layout shifting as components mount, and a bundle full of code that only ever ran once on a server that could have done the work for free. Astro removes that class of problem by construction rather than by discipline.

The framework has kept moving in the same direction. Astro 5.0, released on December 3, 2024, added the Content Layer API for loading content from any source and Server Islands, which let a single component be rendered on demand at request time while the rest of the page stays static. Astro 7.0, published on June 22, 2026, moved to Vite 8 and introduced a Rust based compiler, which mainly shows up as faster builds rather than a different mental model. The philosophy has not shifted: static first, interactive only where you say so.

The tradeoff is worth stating plainly. Zero JavaScript by default means you cannot reach for a browser API inside a component and expect it to work. Directives are not optional decorations, they are the contract. Teams used to writing a single page application in one framework often find Astro awkward for dashboards and heavily interactive tools, and that is a fair verdict: on an app where almost every pixel responds to input, the island model stops paying rent and a client framework should own the page. For the large share of the web that is content with a handful of interactive controls, the default of no JavaScript is not a limitation. It is the design decision that makes the rest of the stack fast.

If you take one practical habit away from this, make it the question you ask before adding a component: does this need the browser at all? In Astro the answer defaults to no. Changing that default costs you an explicit directive, and that small friction is the whole trick. It forces the decision into the open, at the moment the component is used, where a senior developer can actually judge the cost of hydration against the value of interactivity.