Why I chose Astro over Next.js for this portfolio
This site is a portfolio and blog, not an app behind a login. Here's why that shape pointed at Astro instead of Next.js.
I closed out a post about choosing Vite over Next.js by saying that if I ever built something genuinely content-first and SEO-driven, Next.js or Astro would be the right call for that piece. This site is that piece, and I picked Astro.
What this site actually is
A portfolio and a blog: markdown and MDX content, a handful of pages, no login, no per-request data that differs by visitor. Every page can be built once and served as static HTML. That’s a very different shape from the authenticated dashboards and embeddable widgets I reached for Vite on, and it’s a shape Next.js is genuinely built for too. So why not Next?
Islands over a server runtime
Astro ships zero JavaScript by default and only hydrates the specific components that need it: the mobile nav toggle, the theme switcher, the copy-email button. Everything else, including the project write-ups and blog posts, is plain HTML with no client-side framework attached. Next.js can get close to this with server components, but it’s an opt-out from a client-rendered default; Astro’s islands are an opt-in from a static default. For a site that’s 95% prose, opt-in matched the site better than opt-out.
Content collections fit the content
Astro’s content collections gave me typed frontmatter, schema validation with Zod, and a clean
getCollection API for projects and blog posts out of the box. Next.js can do this too, but it
means choosing and wiring up a content layer yourself (or reaching for a CMS). I wanted the content
model to be a first-class part of the framework, not an integration I bolt on.
One deploy story, not two
Because the whole site builds to static files, hosting is just a CDN, the same shape as the Vite apps I already run for work. No server runtime to keep warm, no edge function cold starts to think about, no framework-specific hosting requirements. That consistency matters more to me on a personal project I maintain alone than any server-rendering feature I’m not using.
The honest tradeoff
I gave up server actions, middleware, and the sheer ecosystem gravity Next.js has. If this site ever needs authenticated pages, per-user dynamic data, or heavy server-side logic, Next.js goes back on the table. But for a portfolio and a blog, Astro’s default (ship HTML, hydrate only what moves) was the better fit for the shape of what I was actually building.