Sometimes the best code is the code you don't ship to the browser.
// package.json diff
- "next": "15.3.5",
- "react": "19.0.0",
- "framer-mot...
For further actions, you may consider blocking this person and/or reporting abuse
interesting. I heard about astro but to be honest could not spare time to learn what it is actually. I build my web site with next.js too and my main motivation is writing blogs, though there is none, yet. So i might reconsider my tech stack, later.
thanks for the post
Next.js works great for blogging too, so no rush to switch. The main difference I noticed was how much simpler the setup becomes with Astro for content-heavy sites. But honestly, the most important thing is just starting to write. The framework matters less than the habit. Good luck with your first post!
Exactly, what is what i think truly. Probably, i will stick on this stack for a while, but it is good to know about Astro. Thank you, I am collecting ideas and thoughts currently, but it is already time to turn it to real action :). good luck with your blogs
Good luck with yours too! The hardest part is writing the first one. Once that's out, the rest gets easier. Looking forward to reading it when you publish.
"Using a chainsaw to butter toast" -- I'm stealing that line lol.
Made a similar switch for a docs site I maintain. The dependency list alone was reason enough. We had like 8 packages just for markdown rendering and syntax highlighting, and half of them had breaking changes every few months. With Astro it's basically built in.
The View Transitions API support is underrated too. I was using Framer Motion for page transitions and it added ~60KB to every page. Now I get smoother transitions with literally zero JS cost. The browser just handles it natively.
One gotcha I hit during migration: if you're using any React context providers that wrap your whole app (theme, auth, etc), you'll need to rethink that pattern since Astro doesn't have a persistent app shell. Ended up using a combination of cookies and tiny inline scripts for theme state. Actually cleaner than the React approach was.
Ha, feel free to use it! Good point about the context providers gotcha. I hit the same thing with theme state. Ended up with a small inline script in the head that reads localStorage before paint, which actually prevents the flash of wrong theme better than React context ever did. Simpler and faster.
went through something similar rebuilding a landing page. had Next.js with all the trimmings - ISR, API routes, the works - for what was basically 4 static sections and a contact form. the bundle size was embarrassing. switched to Astro and the lighthouse score jumped before I even touched the CSS. the thing that got me was "what am I actually building here" - that question alone is worth asking before you pick a framework. most sites don't need a runtime
"Most sites don't need a runtime" - that's the whole argument in one line. We reach for full frameworks by default when the content should dictate the tool. Glad the switch worked out for you too.
exactly. and the framework defaults keep creeping up - once you use one feature you start using three more because they're right there. Astro's constraint feels limiting at first but that's kind of the point
Constraints breed focus. When the framework doesn't offer a feature, you ask yourself if you actually need it. Most of the time, the answer is no.
exactly. the constraint forces the decision. most feature sprawl happens because adding something costs nothing in the moment - you only pay later when you are debugging a system with 40 things it can do but nobody remembers why.
Are you hosting on Cloudflare and if so did you find any advantage to using Astro there?
Hosting on Vercel with domain on Porkbun. Deployments are incredibly fast, under a minute from push to live. Astro's static output means Vercel has very little to do at build time compared to Next.js, which had to handle SSR, hydration bundles, and route optimization. Haven't tried Cloudflare Pages but heard good things for static sites.
Cloudflare acquired Astro (blog.cloudflare.com/astro-joins-cl...) so I was curious if they have integrated in any way. By the way Pages is slowly getting morphed into Workers on Cloudflare, so if you try it, start with Workers. The observability log/trace is much better than what you get with Pages.
That's a great point about Cloudflare acquiring Astro. I haven't explored Workers yet but the tighter integration between Astro and Cloudflare's edge network sounds promising, especially for static-first sites. Will definitely look into Workers when I consider moving off Vercel. Thanks for the tip on observability, that's useful to know.
I wrote about migrating to workers so check my profile when you’re ready.
I will look into it. Thanks for suggestion.
love this kind of honest framework comparison. the question "what am I actually building here?" is exactly what millions of developers working on similar content sites should ask themselves. i keep seeing similar discussions on daily.dev about when to use full spa frameworks vs static first approaches. your performance numbers really drive home the point that sometimes the best engineering decision is just using less tech.
Appreciate it. "Using less tech" sounds simple but it's genuinely hard to do when the industry constantly pushes toward more complexity. Glad the numbers spoke for themselves.
This feels very familiar. I’ve had projects where Next.js started feeling like too much framework for what was basically a content site.
That's exactly the moment. Once you realize you're configuring more than you're creating, it's time to simplify.
Yeah exactly, that’s the point where it starts feeling off.
Like you spend more time setting things up than actually building anything meaningful.
Took me a while to realize that “more powerful” doesn’t always mean “better” for every project
Well said. "More powerful doesn't always mean better" is the whole lesson. The best tool is the one that gets out of your way and lets you focus on the content.
I agree!
The Astro migration story resonates — framework bloat is real, especially when you don't need the full SPA complexity. The content-first approach with islands architecture makes so much more sense for most websites.
One thing I've noticed working on AnveVoice (we build voice AI that takes real DOM actions on websites): framework choice matters enormously for accessibility and DOM predictability. Static-first approaches like Astro produce cleaner, more semantic HTML which is actually easier for AI agents to parse and interact with. When your voice AI needs to click buttons and fill forms on a website, having predictable DOM structure is gold. Did you notice any accessibility improvements after the migration?
Great point about DOM predictability. The migration did produce cleaner, more semantic HTML since Astro outputs static markup without React's hydration wrappers and synthetic event layers. Hadn't thought about it from an AI agent perspective, but it makes sense that a predictable DOM is easier for voice AI to parse and act on.
Great comparison! The 230KB → 0KB JS reduction really shows how Astro shines for content-first sites.
Astro's islands architecture is a game changer — keeping React only where it's needed is the right trade-off.
Exactly. Ship JS only where there's actual interactivity. For a blog, that's almost nowhere.
Great writeup. I went through the exact same migration path, Next.js to Astro, and the numbers are almost identical. The 230KB → 0KB JS on blog posts is the stat that convinced me too.
One thing I'd add: the SEO benefits are real and measurable. My Astro blog started getting Google impressions within days of launching, and I'm pretty sure the Lighthouse 99-100 scores and fast TTFB are contributing to that. Next.js static export can get close, but you're fighting the framework to get there.
The content collections DX is what keeps me on Astro though. Drop an MDX file in a folder, it just works. No next-mdx-remote chain of dependencies.
Curious, are you using Astro's built-in sitemap integration? That + the RSS feed were two things I set up in about 5 minutes that would've been custom code in Next.js.
Yes, using both the sitemap integration and @astrojs/rss. You're right, it was maybe 5 minutes total for both. The SEO improvement is something I'm starting to see too. Google Search Console picked up my pages quickly after deploying. And agreed on content collections DX, just dropping an MDX file and having it work with schema validation built in is hard to go back from once you've used it.
Astro is such a power house. good move.