Contents
TL;DR
On Dev.to the author describes migrating a personal site from Next.js 15 (React 19, Framer Motion, GSAP) to Astro 6: for a content blog the React runtime and hydration were unnecessary—the post page stopped shipping JS to the browser.
What happened
v1 was a portfolio flex: animations, dual design modes, markdown via content-collections, next-mdx-remote, react-markdown, starry-night. When focus shifted to a weekly blog, the math looked wrong: ~180 KB framework + ~45 KB React + ~60 KB Framer Motion + ~30 KB GSAP—for static text.
Next.js can SSG, but still hydrates pages: the browser downloads, parses, and runs JS for paragraphs and code blocks.
Astro ships HTML + CSS by default; JS only where interactivity is needed (islands). The author’s whole site uses a tiny inline script for dark mode.
Migration took ~one day: copy MDX posts, keep Tailwind v4 and themes, Shiki built-in instead of starry-night, View Transitions API instead of Framer Motion.
Why it matters
Framework choice is not “Astro vs Next.js forever”—it is fit for the job:
| Scenario | Reasonable pick |
|---|---|
| SaaS, dashboards, e-commerce | Next.js / full React |
| Content blog, docs | Astro / zero-JS-by-default stacks |
Numbers from the post: Lighthouse Performance 85–90 → 99–100, build ~15s → ~5s, dependencies 30+ → ~10.
In practice
- Measure how much JS a typical blog page truly needs—if it is typography and syntax highlighting, React may be overkill.
- In Astro content collections and Shiki cover most needs without content-collections + rehype chains.
- React components remain via
client:loadfor rare widgets. - You do not have to drop portfolio “show” animations for a blog—the author traded morphing layout for publishing speed on purpose.
- Keep the old Next site as an archive—migration need not be all-or-nothing.
Bottom line
A sensible framework fit story: Next.js excels at apps, Astro at content. If your main job is serving markdown fast, zero-JS-by-default often beats using a chainsaw to butter toast.