Next.js or Astro — which I reach for, and when
Astro isn't always the answer. Here's how I decide between a zero-JS Astro site and a full React/Next.js app — and why I keep both in my toolkit.
People sometimes assume that because I love Astro, it’s the only tool I use. It isn’t. Astro is brilliant for content-driven sites — but plenty of projects are genuinely apps, and for those I reach for React and Next.js. Picking the right one is half the job.
My rule of thumb
- Mostly content, mostly static? → Astro. Marketing sites, portfolios, brochure sites, blogs. Ships zero JavaScript by default, scores 90+ on Lighthouse, loads in under a second.
- App-like, lots of client state, per-user data? → React + Next.js. Dashboards, booking systems with live availability, anything behind a login, anything that feels like software rather than a page.
What Next.js gives me that a static site can’t
- Server-side rendering & API routes in one codebase — so a dashboard can fetch fresh, per-user data on every request.
- React’s component model for genuinely interactive UIs — complex forms, real-time updates, multi-step flows with shared state.
- Incremental static regeneration when I want static speed and fresh content.
Both are styled the same way — Tailwind CSS — so the design language and my workflow stay consistent whether I’m shipping an Astro page or a Next.js app.
The honest version
This very portfolio is Astro, on purpose: it’s content, so it should be fast and ship no framework runtime. But when a client needs a booking platform or an internal tool, I don’t force it into the wrong shape — I build it in Next.js. Same engineer, right tool for the job.