Skip to content
Engineering astroperformancearchitectureweb-development

Why We Build With Astro (And When We Don't)

After shipping production sites in Next.js, Remix, and Astro, we settled on Astro for most client work. Here is exactly why — and the cases where we still reach for Next.

Vishnu Sharma
Vishnu Sharma 01 June 2025 · 3 min read
Share this article X LinkedIn WhatsApp

Every time we start a new project, the first real decision is the framework. For most of the last three years that meant Next.js — battle-tested, the ecosystem is huge, and every engineer we have worked with knows it. So switching the majority of our client work to Astro was not a decision we made lightly.

Here is what changed our minds.

The performance argument is airtight

When we built our own site (the one you are reading now) in Astro, we hit Lighthouse scores we had not seen since hand-rolled HTML. Zero JavaScript shipped to the browser by default. Fonts, images, and hero sections loaded with no hydration overhead. The Core Web Vitals numbers were not marginal improvements — they were categorical.

For marketing sites and content-driven products, the performance ceiling in Astro is genuinely higher than in React-first frameworks. Not because Astro is magic, but because it starts from zero and makes you opt in to JavaScript rather than opt out.

Islands architecture matches how client sites actually work

Most pages on a company website are 95% static content with one or two interactive pieces — a form, a navigation menu, a video player. Next.js ships a full React runtime for all of it. Astro ships nothing until you mark a component with client:load or client:visible.

The practical result: we can use Preact for our interactive islands (forms, mobile menu, WebGL hero) and keep the rest of the page as pure HTML. The bundle size for a typical Atlansian client site is a fraction of the equivalent Next.js build.

The developer experience caught up

A year ago Astro’s tooling was rougher than Next.js. That is no longer true. The VS Code extension, TypeScript integration, and content collections API are genuinely excellent. Astro Actions — type-safe server-side functions for forms — made our form handling cleaner than anything we had built in Next.js API routes.

When we still reach for Next.js

Astro is not the right choice for everything. If a project needs:

  • A heavily interactive authenticated app (dashboard, internal tool)
  • Real-time features (live feeds, collaborative editing)
  • A large team already bought into the React mental model with complex client-side routing

…we reach for Next.js or, increasingly, Remix. The framework is not the point — the product is.

But for marketing sites, service websites, content platforms, and landing pages? Astro is our default now, and we have not looked back.

Share this article X LinkedIn WhatsApp
Vishnu Sharma

Written by

Vishnu Sharma

CEO · Head of Company

Vishnu co-founded Atlansian after 7.5 years shipping production-grade products across early-stage startups and scaled enterprises. A full-stack engineer at heart, he leads every client engagement pers…