Why I Chose Astro (and How It’s Going)

I’ve built sites with WordPress. I’ve used Ghost. I’ve even tried rolling my own custom JavaScript-based blog setup. None of them gave me what I wanted.

I wanted a fast, clean, minimal site I could deploy to Cloudflare Pages. WordPress and Ghost are too opinionated, too reliant on server-based rendering, and honestly too bloated for what I was after. I didn’t want to deal with plugins, themes, or constant patching. I wanted semantic HTML, my own CSS, and the option to add JavaScript only where I needed it—not everywhere.

That’s what drew me to Astro.

Getting Set Up

Getting started with Astro was refreshingly simple. I used the CLI to scaffold a minimal app and followed along with their blog tutorial. The documentation was clear and concise. The concepts—like components and content collections—were different from what I was used to, but once I wrapped my head around them, it all made sense.

I built a basic layout system using .astro components: header, footer, social links, and a dark/light theme toggle. My base layout includes a slot for page-specific content, and I created a second layout just for blog posts to maintain consistent structure across the site.

Content is markdown-based. I used content collections for blog posts and wrote some helpers in JavaScript to display recent posts, tag lists, and archives.

No Tailwind, No Inline Styles

I write semantic HTML. I use application-specific class names and back them with a global CSS stylesheet. That’s it. No Tailwind. No inline styles. I like having complete control over the styling without introducing a bunch of utility class noise in my markup.

Islands and Interactivity

Astro’s islands architecture is one of the reasons I chose it. I haven’t fully leaned into it yet, but I like the idea of isolating interactivity where it’s needed. For more complex projects—like my games platform—I’m planning to experiment with islands using React or Web Components for richer interactions.

For now, I’ve stuck to basic static pages, but the architecture gives me confidence that I can scale when I need to.

Build & Deployment

The build process is fast. Really fast. I’m generating static pages and deploying to Cloudflare Pages. Every commit to my GitHub repo triggers a new deployment. Most builds take just a few seconds, even with custom RSS feeds and a sitemap.

The only hiccup I’ve run into so far was with the Astro image component. I got some confusing build errors that took a while to debug. The error messaging still needs work—it wasn’t very helpful. Hopefully that improves with time.

Integrations & Future Plans

Right now I’m using the sitemap integration, and I plan to explore others. I’d love to see an official Google Analytics integration—or at least some guidance on handling analytics in a privacy-first way. Brave and similar browsers block client-side tracking, so server-side options may be the better path.

One thing I’m intentionally avoiding is overcommitting to Astro-specific APIs. As much as I like it, I don’t want to box myself in and end up rewriting my whole site because of breaking changes. So far, Astro has been solid, but I’m staying cautious.

Final Thoughts

Astro hits the sweet spot for small static content sites. If you’re building a personal blog or something similarly scoped, it’s a great choice. Fast builds, clean markup, custom styling, and just enough interactivity when you need it.

I’ll keep exploring what it can do—especially with islands, integrations, and scaling content—but for now, Astro has delivered on its promise: performance, simplicity, and developer control.