Development

Astro 5: Why Zero-JavaScript Architecture Became the Sensible Default

Rupam ·

Astro is the framework that finally made “ship as little JavaScript as possible” the default rather than something developers had to fight for. Astro 5, released late 2024, made the case stronger: server islands, content layer abstractions, type-safe content from any source, and an even faster build pipeline. For content-heavy sites, Astro is now the default we reach for at EtherLabz.

Key takeaways

  • Astro’s island architecture is the right default for content sites. Static HTML by default, JavaScript only where interactivity is genuinely needed. Marketing sites end up shipping kilobytes of JS instead of megabytes.
  • Server islands solve the hybrid rendering problem cleanly. Mostly static pages with small dynamic regions (live cart count, personalized recommendations, real-time data) work without abandoning the static-by-default model.
  • Content collections are typed first-class data sources. Astro 5’s content layer treats Markdown files, MDX, headless CMS data, and even API responses as typed collections that the rest of your code can reason about with TypeScript.
  • It’s not a Next.js replacement for application UIs. Astro is the better choice for content; Next.js or Remix is still the better choice for authenticated apps with heavy interactivity. Pick the right tool.

What changed in Astro 5

Content Layer

Pre-Astro 5, content collections were limited to local files (Markdown, MDX, JSON in your repo). Astro 5’s Content Layer treats any data source — a headless CMS, a remote API, a database — as a typed content collection. The same query patterns work whether your content is in src/content/blog/ or in Sanity or in a Postgres database. This is a meaningful architectural simplification.

Server Islands

Server islands let you mark specific components in an otherwise-static page as server-rendered at request time. The static page ships immediately; the dynamic regions render on the server when requested and slot in. Use case: a static product page with a live “others bought this” recommendation that needs to query the database. Pre-server-islands, you’d either ship a fully client-side component (and pay the JS cost) or render the whole page on the server (and lose the static performance benefits). Server islands handle this cleanly.

View Transitions

Astro’s View Transitions API integration enables smooth page transitions between routes without going full SPA. The page is still server-rendered HTML; transitions are layered on via the browser’s native View Transitions API. The result feels app-like without the JavaScript overhead.

Faster build

Astro 5’s build is roughly 2–3x faster than Astro 4 for typical content sites, mostly through better caching and parallelization. For sites with thousands of pages, this changes deployment dynamics meaningfully.

The architectural fit

Astro is the right tool for:

  • Marketing sites and landing pages
  • Documentation sites
  • Blogs and content platforms
  • Brochure sites and portfolios
  • Hybrid sites where 80%+ of pages are static content with small dynamic islands

It’s not the right tool for:

  • Authenticated SaaS dashboards with heavy interactivity
  • Real-time applications (chat, collaborative editing)
  • Apps where every page is rendered with user-specific state
  • Frontends that need React’s full ecosystem of hooks-based state management

The hybrid pattern that’s becoming common: Astro for the marketing site (etherlabz.com style), Next.js or Remix for the authenticated app (app.etherlabz.com). Both deployed independently, sharing only the design system.

Performance numbers

Astro sites consistently produce small bundles and fast Core Web Vitals. Typical numbers for a content site:

  • JavaScript bundle: 0–20KB compressed for static pages, 30–80KB if islands include React/Vue components
  • LCP: under 1 second on global CDN delivery
  • INP: under 200ms (most pages have minimal client-side JS, so interaction is fast by default)
  • Lighthouse score: 95–100 across categories without optimization heroics

The performance comes from architecture, not optimization tricks. You don’t fight to keep the bundle small; the framework keeps it small unless you explicitly opt into more JS.

Migration patterns

Common migration paths to Astro:

From WordPress (monolithic)

Keep WordPress as the CMS, build the public site in Astro consuming WordPress’s REST or GraphQL API. The migration is: build the new Astro site against your existing WordPress content, run them in parallel for a transition period, cut DNS to the Astro site, retire the public-facing WordPress. The admin remains on WordPress; only the public site changes.

From Next.js (content-heavy)

Apps that started in Next.js but ended up content-heavy often migrate selectively. The marketing site (homepage, about, blog) moves to Astro; the authenticated app stays in Next.js. The build complexity reduces, performance improves, and the team’s mental model gets clearer.

From Gatsby

Gatsby’s static-site generation predates Astro but has fallen behind on developer experience and build performance. Migrations from Gatsby to Astro are common and relatively straightforward — the content models translate well, and Astro’s content collections are conceptually similar to Gatsby’s data layer with less ceremony.

What to know before adopting

  • The Astro component syntax is .astro, not .jsx. Components compile to HTML at build time. JSX-style React components work via integration but as islands, not as the default.
  • Hosting choices. Vercel, Cloudflare Pages, Netlify all support Astro natively. Server islands and SSR features depend on host runtime support; check the integration matrix.
  • Plugin ecosystem is smaller than Next.js. Most things have integrations or community packages, but you’ll occasionally need to write a small wrapper that would have been a npm install in Next.js.
  • Image optimization works well. Astro’s <Image> component handles modern formats, responsive sizes, and lazy loading. Image performance is a strength.

FAQ

Is Astro production-ready for serious sites?

Yes. Major sites running on Astro include framer.com, the official React documentation, and many enterprise marketing sites. The 5.x release line is stable.

Can I use React components in Astro?

Yes — via Astro’s React integration. React components become islands that hydrate client-side. The rest of the page remains static HTML. Same pattern works for Vue, Svelte, Solid, and Preact.

How does Astro compare to Next.js for a marketing site?

Astro produces smaller bundles, faster builds, and better default performance for content. Next.js is more familiar to React developers and has better app-style ergonomics. For pure marketing sites, Astro wins on the metrics that matter; for sites that mix marketing and app surfaces, Next.js’s unified model is simpler operationally.

Does Astro support SSR or only static generation?

Both. Static is the default, but Astro supports server-side rendering, hybrid rendering, and now server islands. The framework lets you mix rendering modes per route or per component as needed.

What about i18n / multi-language sites?

Astro 5 has solid i18n support: routing, content collections per locale, fallback chains. For sites with significant translated content, Astro’s static-first model handles i18n efficiently — each locale is a static build target.

Want help with an Astro build or migration?

EtherLabz builds and migrates content sites to Astro — including our own v2 site. Book a discovery call.

Written by Mradul, with input from the EtherLabz team.