// Why I Switched to Astro

My last personal site was a Next.js app. It worked fine. The developer experience was good, deploys were fast, and I knew the framework well. But every time I looked at the network tab, I was sending 200kb+ of JavaScript to render what was essentially a list of blog posts. Nobody was complaining, but I was.

I’d heard about Astro for a while and kept dismissing it as a niche tool for content sites. Which is exactly what a personal blog is. Eventually I ran out of reasons not to try it and spent a weekend migrating. The migration took less time than I expected and the result shipped less than 10kb of JavaScript by default. For a site with no interactivity, that’s just correct behavior.

What I didn’t expect to like as much as I do is the component model. Astro components feel like a cleaned-up version of what web templates always wanted to be — frontmatter for data, HTML for structure, scoped styles that actually stay scoped. When I need React or Svelte for an interactive component I can drop it in with a directive. The rest stays static. This opt-in approach to JavaScript is the right default for most sites.

Content collections were the other thing that won me over. Markdown files with typed frontmatter, validated at build time — it’s a small thing but it removes a whole category of “why is my post not showing up” debugging. The schema is defined once and the rest follows from it.

I don’t think Next.js is wrong for anything. For apps with real interactivity, server components, complex data fetching — it’s still the right tool. But for a site that publishes text, Astro fits the problem more precisely. That fit shows up everywhere: in build times, in bundle sizes, in the fact that the framework never gets in the way because it’s barely doing anything.