I spent two years shipping things with Next.js. It’s a good framework. But when I started building kuloreza.dev, I reached for Astro instead. Not because Next.js is bad, but because this particular problem didn’t need what Next.js offers.
The Misalignment
Next.js excels at applications — places where interactivity, state, and real-time updates are central to the experience. It gives you data fetching at the server level, fine-grained control over rendering strategies, and a powerful API layer built in.
A portfolio site with blog posts, project showcases, and code exercises is mostly content. Static pages that don’t change between builds. A few interactive React islands where they’re actually needed.
Next.js felt like using a power drill to hang a picture frame.
What Astro Brought
Static by default. Every page ships as HTML. No JavaScript payload unless you opt in with islands. The homepage, blog, work section — all fast.
Markdown/MDX as a first-class citizen. I can write content as .mdx files, organize them in the filesystem, and let Astro handle routing. Next.js can do this, but it requires reaching for separate tooling.
Simpler mental model. Pages are Astro components. Interactive sections are React islands. That’s it. No hybrid rendering modes to reason about, no Suspense boundaries to debug.
Zero config for what I needed. Out of the box, Astro handles CSS, image optimization, and code splitting. I didn’t need to think about webpack.
The Real Reason
The honest answer: I wanted to learn Astro. Next.js was comfortable. Comfortable doesn’t teach you anything new.
If I were building a real-time collaborative editor or a multi-tenant SaaS dashboard, I’d reach for Next.js again without hesitation. But for a site that’s mostly words and images, Astro was the right tool and the learning opportunity.