Why I Chose Astro for This Site

Every framework choice is a bet. You’re betting on the tool’s future, on your own ability to learn it, and on whether it’ll still make sense a year from now when you’re debugging it at midnight.

Here’s why I bet on Astro — and what I’ve found six months in.

What I was looking for

I needed a site that’s fast, easy to deploy, and doesn’t make me fight the framework to do simple things. I’ve used heavier stacks — React SPAs, Next.js apps — and they’re powerful, but they carry weight.

For a personal site with a blog and some tools? That weight is waste. I don’t need client-side routing for a page that doesn’t change. I don’t need a full React tree to display a word counter that runs in 40 lines of vanilla JavaScript.

The question I asked myself: what’s the simplest thing that does what I need? The answer was Astro.

What Astro gets right

Zero JS by default. Every page ships as static HTML unless you explicitly opt into JavaScript. This isn’t just good for performance — it forces clarity. You don’t reach for JS out of habit; you reach for it when there’s no other option. The discipline this creates is genuinely valuable.

Islands architecture. When you do need interactivity, you hydrate just the component that needs it. The word counter on this site uses a small interactive island — a textarea and a script. The rest of the page is static. The result: instant load, no layout shift, no hydration waterfall.

File-based routing. Create a file in src/pages/, you get a route. This is the right level of magic — obvious enough that you never forget how it works, powerful enough that you don’t need to configure anything. New tool? New file. That’s the entire workflow.

Content Collections. This blog runs on Astro’s Content Collections feature. Each post is a Markdown file with typed frontmatter. If I forget a required field, TypeScript catches it before it builds — not after a confused 404 in production. Collections also make filtering, sorting, and rendering posts trivial. There’s no database query to write, no API to call.

The @astrojs/sitemap integration generates a proper XML sitemap automatically from all prerendered pages. One package, three lines of config, done. It would take me longer to write a sitemap by hand than to set this up.

Where it surprised me

The Cloudflare Pages deployment is suspiciously easy. Push to GitHub, connect the repo, set build command to npm run build and output to dist/. That’s it. The site deploys in under 30 seconds and sits on Cloudflare’s edge network globally.

I expected more friction. There wasn’t any. The first time I deployed, I half-expected something to be wrong. It wasn’t. Just a fast, static site on the edge.

The hybrid rendering mode — where most pages are static but you can opt individual routes into SSR — is more useful than I expected. It means I’m not forced to commit to “fully static” or “fully server-rendered” upfront. I can make that decision per route.

Astro vs Next.js: the honest comparison

I’ve shipped projects in both. Here’s the honest version:

Next.js is the right choice when you need: client-side navigation between pages, React Server Components, API routes with complex server-side logic, or a large team that already knows React deeply.

Astro is the right choice when you need: maximum performance with minimum JS, a blog or content-heavy site, a collection of interactive tools that don’t share state, or a site you want to deploy for free on Cloudflare or Netlify.

For this site — a portfolio, blog, and tool collection — Next.js would have been a significant over-investment. I’d be shipping kilobytes of JavaScript to serve content that doesn’t need any.

How this affects the tools I build

The performance constraints are actually creative constraints. When you can’t reach for a heavy charting library on a whim, you write the SVG yourself. When you can’t dump everything into a React component, you think harder about what actually needs to be interactive.

The tools on this site — Word Counter, Text Case Converter, Base64 Encoder/Decoder — are all pure HTML with a small script. They work instantly, they load instantly, and they don’t need a CDN, a subscription, or a build step beyond what Astro already does.

That’s the kind of tool I want to build. Fast by default, private by design, and lightweight enough that a 3G connection on a five-year-old phone still gets a good experience.

Astro makes that natural. More importantly, it makes that the path of least resistance — which is what determines what actually gets built.

Should you use Astro?

If you’re building a content site, a portfolio, or a collection of focused tools: yes, with confidence.

If you’re building a complex single-page application with heavy client-side state, routing, and real-time data: look at Next.js or Remix instead. Astro is not trying to be those things, and that honesty is one of the things I respect about it.

Pick the tool that matches the problem. For most personal sites, the problem is: ship something fast, keep it maintainable, don’t pay for hosting. Astro solves all three.