Why I Use Astro with React Islands
How Astro's island architecture lets me keep the site mostly static while using React only where interactivity earns its place.
When I rebuilt this portfolio, I had a straightforward stack choice: Next.js, Remix, plain HTML, or Astro. I went with Astro, and React islands were the deciding factor.
The problem with full-React sites
A portfolio is mostly static content: text, images, case studies, and notes. Shipping a full React runtime for that can be expensive if only a few parts of the page actually need JavaScript. Users pay for it in bundle size, hydration time, and often a lot of unnecessary motion.
Islands are the useful middle ground
Astro flips the default. Everything ships as static HTML unless I opt into client-side JavaScript for a specific component.
On this site, the interactive pieces are small and deliberate:
- The navigation dock, because theme switching and interaction need to feel immediate
- The footer, because it only needs hydration when it becomes visible
- A few motion-heavy React components where the payoff is clear
Everything else stays static. That keeps the baseline fast and the architecture easier to reason about.
What that buys me
The site loads quickly, the HTML stays lightweight, and I still get to use React where it actually helps. It is a good fit for portfolios, editorial sites, and product marketing pages where most of the experience should be readable before JavaScript even wakes up.
When I still reach for React
React islands are still useful when I need:
- Stateful UI such as toggles, filters, or interactive controls
- Motion components that need runtime orchestration
- Third-party libraries that expect a React environment
For everything else, .astro components are enough.
The main reason I keep coming back to Astro
It lets me be strict about where interactivity belongs. That alone improves performance, but it also improves taste. If a component needs hydration, it has to justify itself.