Why I Chose Astro Over React

React won. There’s no denying it — if you need a framework for a web app, React is the default choice. The ecosystem, the hiring pool, the mental model. Everyone knows React.

But “everyone knows React” isn’t always the right reason to use it. And a lot of websites that ship with React don’t need React.

I built this portfolio with Astro. Here’s why, what it cost me, and where I’d pick something else.

The Problem With React for Static Content

This site is a portfolio. It has a landing page, a project listing, a blog, and individual project/blog detail pages. That’s it. No user authentication, no real-time features, no complex state management.

The entire dynamic behavior is:

Filter project cards by tag
Switch between project and blog tabs
Search across content
Toggle a theme

That’s maybe 300 lines of vanilla JavaScript. No framework needed.

Yet I could build this same site in React — Next.js, Remix, Vite + React — and ship 200+ KB of JavaScript (before gzipping, before code splitting, before tree shaking) to render static text.

Astro ships zero JavaScript by default. Not “most” JavaScript. Zero. Every component is rendered to static HTML unless you explicitly opt into interactivity with client:load, client:visible, client:only, or client:always. That’s the core idea behind Astro’s islands architecture.

Islands Architecture, Actually

Islands architecture isn’t a buzzword — it’s a constraint, and constraints are good. Astro forces you to think about which parts of your page actually need JavaScript. Everything else stays static. For my portfolio, that means:

The hero section renders as HTML. The typewriter animation and parallax are a small script attached to specific elements.
The project cards render as HTML. Filtering and search are separate small scripts.
The theme toggle is a button with a delegated event listener.
The navigation menu on mobile is a checkbox-based drawer — no JavaScript at all.

The only framework-level JavaScript that runs is from <ClientRouter />, which handles view transitions between pages. That’s it.

Compare that to a React app where every page — even one with a single button — ships the full React runtime plus the component tree. Astro’s trade-off is clear: you write more explicit hydration annotations, but you only pay for what you use.

The Trade-Offs

This isn’t a “Astro > React” argument. It’s a “Astro for X, React for Y” argument. Here’s where Astro falls short:

No server-side rendering on demand. Astro is a static site generator first. You can do server rendering with adapters (Node, Vercel, Cloudflare), but the experience isn’t as polished as Next.js. If your content changes frequently and you need server-rendered pages, Astro is the wrong tool.

Limited reusability outside the framework. React components are just functions that return JSX. They work anywhere — on the web, in mobile (React Native), in desktop apps (Electron, Tauri), in the terminal. Astro components are tied to Astro. ProjectCard.astro doesn’t translate to a React component. If you’re building a multi-platform product with a shared design system, Astro won’t give you that.

No client-side routing. Navigation in Astro is page-based. Every link triggers a full page load (with View Transitions for smoothness). You don’t get client-side route transitions, lazy-loaded route components, or the kind of SPA-like navigation that makes apps feel instantaneous. For a content site with a handful of pages, this is fine. For an app with dozens of routes, it gets old fast.

Smaller ecosystem. React has thousands of UI libraries, hooks, utilities, and tools. Astro has a few. If you need a specific React component library (MUI, shadcn/ui, Radix), it won’t work in Astro. You’re limited to Astro-specific component libraries or raw HTML/CSS/JS.

What Astro Is Good At

If your site fits the mold — content-driven, low interactivity, high performance requirements — Astro is genuinely excellent:

Content Collections with Zod validation. Built-in support for MDX, Markdown, and JSON as first-class content sources. No headless CMS required.
Performance. Zero JavaScript by default means faster initial loads, lower bandwidth, better Lighthouse scores. You don’t have to engineer for performance — it’s the default.
Developer experience. You can drop React, Vue, or Svelte components into an Astro project without setting up a framework-specific build. They get hydrated automatically. This is useful if you’re migrating an existing React component library but don’t need the full framework.
Build-time typing. Content is validated at build time. Broken content fails the build. No runtime surprises.

When I’d Pick React

Here’s when I’d go back to React:

Building an app, not a site. Dashboards, admin panels, collaborative tools, anything that requires complex state, real-time updates, or heavy user interaction. React’s component model, hooks, and ecosystem are built for this.
Team familiarity. If your team already knows React, the velocity advantage is real. Context switching between frameworks has a cost, and it compounds over months of work.
Multi-platform. If you need the same component logic on web, mobile, and desktop, React’s ecosystem gives you a path. Astro doesn’t.
Frequent content changes. If your content changes more often than your code, you need server-side rendering with dynamic data. Astro can do it, but Next.js does it better and with more tools.

Why I Built This Portfolio With Astro

Three reasons, in order of importance:

Performance is the point. A portfolio site is a demonstration of engineering taste. If you’re building a site about your work and it takes 3 seconds to load because of React overhead, you’ve already lost.
The content is the content. Projects and blog posts are the reason this site exists. Astro treats content as a first-class concept rather than something bolted on after the framework decision. That matters when you’re writing a lot of content.
Less infrastructure. No API routes to maintain, no hydration mismatches to debug, no useEffect dependencies to track. The only interactivity is what I explicitly wired up, and I can do that in plain JS. Simpler code means I spend more time writing content and less time wrestling with framework quirks.

The Honest Conclusion

Astro isn’t a better framework than React. It’s a different framework that makes different trade-offs. If your site is content-focused and you care about performance, it’s an excellent choice. If you’re building a complex interactive application, it’s the wrong choice.

The fact that Astro exists gives React teams an important counterweight: not every web project needs a framework. Sometimes the best architecture is no architecture at all.

This site is live at theovisagie.com. Every byte shipped was intentional.