When I launched my first personal site, I almost defaulted to Next.js — the industry standard with a massive community, the shadcn/ui ecosystem, and tutorials everywhere. But I stopped, thought about what I actually needed, and chose Astro instead. Here's why.
The mismatch between tool and task
My site is essentially a markdown renderer with opinions: five pages, no forms, no authentication, no database, no mutations. The only interactive elements are a theme toggle and some scroll-driven CSS animations. Astro is built for exactly this — it's a markdown renderer with opinions. Next.js, by contrast, is a full-stack backend framework that can also render markdown. Using it for a simple blog would be like hiring an entire engineering team to run a one-person site. Every unused feature — middleware, route handlers, server actions, ISR, edge runtime — still adds build time, bundle size, and decision fatigue.
What Astro gives me
Astro ships zero JavaScript by default unless I explicitly opt into a client island. My hero section's skill-tag animation uses `animation-timeline: scroll()` — pure CSS, no React, no hydration cost. (As of April 2026, that property works in Chrome and Edge but isn't yet Baseline, so I wouldn't use it in a production product.) Content collections provide typed frontmatter via Zod schemas: I write a twelve-line `content.config.ts`, drop an `.mdx` file into `src/content/posts/`, and get end-to-end typing automatically — no custom loader, no API route, no database client. Shiki is the default code highlighter, supporting dual light/dark themes with a single config block and a CSS media query — no PrismJS, no rehype chains, no copying highlight.js CSS from 2018. MDX integrates via `@astrojs/mdx` if I need React components inside a post.
What I'm giving up — and when I'd go back
I lose server actions (unneeded for a site with no mutations) and dynamic request-time routes (everything pre-renders at build, and Astro supports API routes if that changes). The main cost is muscle memory: Astro's `.astro` syntax felt like JSX with amnesia for the first hour, then like HTML that finally got proper imports. For an admin dashboard, full-stack e-commerce, or anything with real auth and a database, I'd reach for Next.js without hesitation — or Hono with a lighter frontend for API-first products. The question is always where the complexity lives: if it's in content, pick a content framework; if it's in mutations and state, pick a full-stack framework. "Just use Next.js for everything" is a reasonable default — it works, it ships, you don't have to think. But the cost is that you stop matching the tool to the problem, and that atrophies judgment. Picking Astro for this site took 20 minutes, and those 20 minutes are the whole point.