developmentstrategy

Why I Chose Astro for My Personal Site (And When You Should Too)

After building sites with React frameworks for years, I switched to Astro. Here's the reasoning behind that choice, what makes Astro different, and when it's the right tool for your project.

· 5 min read

This site runs on Astro. After years of building with Next.js and Gatsby, that might seem like a step backward. It’s not—it’s choosing the right tool for the job. Here’s the thinking behind that decision.

The Core Problem with JavaScript Frameworks

Most content websites—blogs, marketing sites, documentation, portfolios—are fundamentally static. The content doesn’t change based on user interaction. There’s no complex client-side state. Yet we’ve been shipping megabytes of JavaScript to render what could be plain HTML.

A typical Next.js site ships 200KB+ of framework code before your actual content. For an application with real interactivity—dashboards, forms, real-time features—that’s a reasonable trade-off. For a blog? It’s wasteful.

The performance implications are real:

  • Slower initial page loads: JavaScript must download, parse, and execute before content is interactive
  • Higher bandwidth costs: Especially impactful on mobile and in developing markets
  • Worse Core Web Vitals: Google explicitly factors page speed into search rankings
  • Accessibility issues: JavaScript-dependent content can fail for users with older browsers or assistive technology

Astro’s Philosophy: Ship Less JavaScript

Astro’s approach is simple: ship zero JavaScript by default. Every page is pre-rendered to static HTML. JavaScript is added only where you explicitly need it.

For this site, that means:

  • Static HTML for all content pages
  • JavaScript only for the theme toggle and mobile menu
  • Total JS shipped: under 5KB

Compare that to the 200KB+ baseline of most React frameworks. The performance difference is noticeable—pages load instantly.

Islands Architecture: Interactivity Where You Need It

Astro doesn’t abandon JavaScript—it just makes you intentional about it.

The “Islands” architecture lets you hydrate individual components while keeping the rest of the page static:

---
import StaticHeader from "./Header.astro";
import InteractiveSearch from "./Search.tsx";
---

<StaticHeader />
<InteractiveSearch client:load />

The header renders as static HTML. The search component loads JavaScript because we explicitly told it to with client:load.

Other loading strategies:

  • client:load: Load immediately
  • client:idle: Load when browser is idle
  • client:visible: Load when component scrolls into view
  • client:media: Load based on media query

This granularity is powerful. A heavy chart component can load only when scrolled to, saving kilobytes for users who never reach it.

Framework Agnostic: Use What You Know

Here’s where Astro gets interesting: you can use React, Vue, Svelte, Preact, Solid, or Lit—even mix them on the same page.

For this site, I use:

  • Astro’s native components for static content (most of the site)
  • No framework for the interactive bits—vanilla JavaScript is fine for theme toggles

But if I needed a complex interactive widget, I could drop in a React component without rewriting everything. That flexibility is valuable.

Content Collections: Built-In Content Management

Astro’s content collections provide type-safe content management without an external CMS:

// src/content/config.ts
const blog = defineCollection({
    type: "content",
    schema: z.object({
        title: z.string(),
        pubDate: z.coerce.date(),
        description: z.string(),
        tags: z.array(z.string()),
        draft: z.boolean().optional(),
    }),
});

Write content in Markdown or MDX. Get full TypeScript support, frontmatter validation, and automatic slug generation.

For a personal site or blog, this eliminates the complexity of setting up a CMS. For larger projects, you can still connect to headless CMS systems like Contentful or Sanity.

The Developer Experience

Building with Astro is genuinely pleasant:

Fast development server: Hot module replacement that actually works. Changes appear instantly.

Intuitive file-based routing: src/pages/about.astro becomes /about. No routing configuration needed.

Sensible defaults: Automatic sitemap, RSS feed support, image optimization—batteries included.

TypeScript throughout: Full type safety without complex configuration.

Great documentation: Astro’s docs are among the best in the ecosystem.

Performance Results

The numbers speak for themselves. This site:

  • Lighthouse Performance: 100
  • Time to First Byte: Under 100ms
  • First Contentful Paint: Under 500ms
  • Total JavaScript: ~4KB
  • Total page weight: Under 100KB for most pages

That’s not careful optimization—that’s what you get out of the box with Astro’s architecture.

When Astro Isn’t the Right Choice

Astro isn’t a universal solution. I’d still reach for Next.js when:

  • Building a web application: Dashboards, SaaS products, anything with significant client-side state
  • Real-time features required: Chat, live updates, collaborative editing
  • Heavy client-side interactivity: Complex forms, drag-and-drop, rich text editing
  • Team already invested in React: Switching costs are real

The distinction: is this primarily content or primarily application? Content → Astro. Application → Next.js (or similar).

The Migration Path

If you’re considering Astro for an existing site:

  1. New projects: Just start with Astro. The learning curve is gentle.

  2. Simple sites: Direct migration is often straightforward. Astro’s component syntax is similar to JSX.

  3. Complex React sites: Use Astro’s React integration. Migrate page by page, converting to Astro components where interactivity isn’t needed.

  4. Large applications: Probably not worth migrating. Use Astro for new content-focused sections, keep existing app as-is.

The Bigger Picture

The JavaScript ecosystem has a history of over-engineering solutions. We’ve shipped enormous bundles for sites that could have been static HTML. We’ve added build complexity for marginal developer experience gains.

Astro is a course correction. It asks: what does this project actually need? For content-focused sites, the answer is usually: not much JavaScript.

That’s not a limitation—it’s a feature. Fewer dependencies mean fewer security vulnerabilities. Less JavaScript means faster pages. Simpler architecture means easier maintenance.

The framework wars are largely noise. What matters is choosing tools that match your needs. For content sites, that tool is increasingly Astro. For applications, it’s something else. Both are valid.

Pick the right tool. Build something fast. Ship it. That’s what matters.