acqme.dev

Recovering from Framework Fatigue: Why I Switched to Astro

•5 min read

Introduction

I hit a breaking point last Tuesday.

I was trying to update the footer on a marketing site built with the latest, greatest React meta-framework. It should have been a five-minute task. Instead, I spent three hours debugging a hydration mismatch because the server rendered the current year as 2025 but the client, running in a different time zone, rendered 2026.

Then I fell down a rabbit hole of configuring middleware.ts to exclude the footer from aggressive caching headers, only to realize I needed to convert the entire layout to a Client Component because I used window.innerWidth in a completely unrelated hook.

I closed my laptop. I walked outside. I asked myself: "Why am I shipping 200kB of JavaScript to render a static footer?"

The answer is Framework Fatigue. We have over-engineered the simple web into oblivion. And the cure is Astro.

The Problem: The "App" Delusion

We collectively hallucinated that every website is a web application. We treat a static About page with the same architectural weight as a real-time stock trading dashboard. We pay the "hydration tax" on every single pixel.

If you inspect the network tab of a standard Next.js marketing site, you'll see a waterfall of JSON and JS chunks executing before the user can interact. We are optimizing for the 10% of the page that is interactive (the newsletter form, the dark mode toggle) at the expense of the 90% that is just text and images.

The Complexity Spirals

It starts innocent. You choose a heavy framework because "we might need state later."

  1. State Management: You add Redux/Zustand because passing props is annoying.
  2. Routing: You fight with the App Router's complex caching heuristics.
  3. Optimization: You realized your LCP is trash, so you install sharp and configure image optimization pipelines.

Suddenly, your personal blog requires a Kubernetes cluster to deploy.

The Deep Dive: How Hydration Actually Works

To understand why Astro is different, we have to look at the mechanics of "Hydration."

In a traditional SPA (Single Page Application) or SSR (Server-Side Rendered) React app, the browser performs a "double render":

  1. HTML Paint: The server sends a string of HTML. The user sees the content.
  2. JS Execution: The browser downloads bundle.js. React boots up, re-runs every single component logic, compares the Virtual DOM to the Real DOM, and attaches event listeners.

This is the Uncanny Valley. The user sees a button, but clicking it does nothing because the JS hasn't finished loading. This is "Time to Interactive" (TTI), and it kills conversion rates.

Astro's Island Architecture

Astro takes a fundamentally different approach. It strips the JavaScript at build time.

When you build an Astro component, it runs on the server (or during the build). It generates static HTML. Then, Astro throws away the component code.

// Input: Astro Component
---
const title = "Hello";
---
<h1>{title}</h1>

// Output: Browser receives ONLY this
<h1>Hello</h1>

There is no React runtime. There is no Virtual DOM. There is no hydration. The browser just renders HTML, which it is incredibly fast at doing.

The Solution: Islands Architecture & Server Islands

Astro flips the model. It doesn't treat your content as a second-class citizen in a JavaScript app. It treats your JavaScript as an island in a sea of static HTML.

By default, Astro ships Zero JavaScript. None. Nada.

1. Client Islands

You can selectively "hydrate" only the interactive bits using directives.

// This component renders as pure HTML. No JS sent to browser.
<Header />

// This component hydrates immediately on load.
<InteractiveSearch client:load />

This is the relief I was looking for. I can use React for the search bar (where it excels) and plain HTML for the footer (where React is overkill).

2. Server Islands (The 2026 Standard)

The biggest innovation in Astro 5.0 was Server Islands. Historically, if you wanted personalization (like "Welcome back, Alejandro"), you had to opt out of caching for the entire page.

Server Islands solve this by caching the static shell at the Edge, and streaming in the dynamic bits asynchronously.

<ProductDetails />
<Reviews />

<!-- This runs on the server, decoupled from the main request -->
<UserRecommendations server:defer>
  <div slot="fallback">Loading recommendations...</div>
</UserRecommendations>

The user gets the static content instantly (Edge-cached), and the personalized bits stream in. It feels like Next.js PPR (Partial Prerendering), but without the Vercel vendor lock-in.

The Content Layer: Type-Safety that Works

In the React world, I used Contentlayer. Then it died. Then I used MDX remote. Then I wrote my own parser.

Astro just... handles it. The Content Layer validates your Markdown/MDX against a Zod schema, giving you strict TypeScript types for your blog posts or product catalog.

// content.config.ts
const blog = defineCollection({
  loader: glob({ pattern: "**/*.md", base: "./src/content/blog" }),
  schema: z.object({
    title: z.string(),
    isDraft: z.boolean(),
  }),
});

I didn't have to install three plugins and configure a next.config.js to get this. It's the default.

The Migration Guide: Escaping Next.js

Leaving the Next.js ecosystem can feel daunting because it provides so many primitives (next/image, next/link, useRouter). Here is how you map those concepts to Astro.

1. Routing

Next.js uses a file-system router (app/page.tsx). Astro does too (pages/index.astro).

  • Next.js: app/blog/[slug]/page.tsx
  • Astro: pages/blog/[slug].astro

The difference is that in Astro, getStaticPaths() is explicit. You tell the build engine exactly what pages to generate. It’s not magic; it’s code.

2. The Link Component

In Next.js, you must use <Link> for client-side navigation. In Astro, you use <a>.

  • Why? Because Astro uses Multi-Page Apps (MPA) by default. Navigating to a new page performs a full browser refresh.
  • "But I want SPA feels!" Astro added View Transitions. You add one line of code: <ViewTransitions /> in your layout, and suddenly your MPA feels like a smooth SPA, preserving scroll position and animating between states.

3. Global State

This is the hardest mindset shift. In Next.js, you wrap your app in a ContextProvider. In Astro, since components don't share a React tree (they are islands), you can't use React Context between them.

The solution is Nano Stores. It’s a tiny, framework-agnostic state library.

// store.ts
import { atom } from 'nanostores';
export const isCartOpen = atom(false);

// Header.tsx (React)
import { useStore } from '@nanostores/react';
import { isCartOpen } from '../store';

export const Header = () => {
  const $isOpen = useStore(isCartOpen);
  return <button onClick={() => isCartOpen.set(true)}>Cart</button>;
}

This works across framework boundaries. A Svelte button can open a React cart.

Performance: The "Time to Interactive" Win

I ran a benchmark comparing my old Next.js portfolio vs. the new Astro version. The results were startling.

  • LCP (Largest Contentful Paint): Next.js (1.2s) vs Astro (0.8s).
  • TBT (Total Blocking Time): Next.js (150ms) vs Astro (0ms).
  • JS Bundle Size: Next.js (180kB gzipped) vs Astro (12kB gzipped).

The 12kB in Astro was just for the theme toggle and the mobile menu. Everything else was HTML. This means my site loads instantly on a 3G connection in a subway tunnel.

Conclusion: The Joy of HTML

Astro reminded me that the web is fundamentally simple. It is a document delivery system.

When I open an Astro project, I see pages/index.astro. I see HTML. I see CSS. I don't see a "use client" directive. I don't see a useEffect triggering a double-render. I just see my content.

For dashboards and Gmail clones, highly interactive SPAs remain king. But for the content-rich web—portfolios, docs, newspapers, e-commerce—Astro is the objectively superior architecture. It respects the user's battery life, and more importantly, it respects the developer's sanity.

What to do next: Take your portfolio. Run npm create astro@latest. Copy your components folder over. See how much code you can delete. The answer will surprise you.