Confession: I built the same marketing site twice last year. Once in Next.js because I’d been living in App Router land for months and reached for what I knew. Then again in Astro three weeks later, because the first build kept shipping a 280KB JS bundle to render four cards and a hero image. Same content. Same designer. Same client. The Astro version came in at 14KB of JS on the home page and stopped being a thing I had to defend in performance reviews.<\/p>\n
I’m not here to tell you Astro wins. It doesn’t, for the work I usually do. But the decision rule isn’t “which framework is better,” it’s “which one matches the shape of the site I’m building.” So here’s how I actually pick now, with the receipts.<\/p>\n
Both ship HTML. That’s where the similarity stops.<\/p>\n
Next.js, with the App Router, treats every page as a React tree. The server renders it, ships HTML, then hydrates the whole thing on the client so React can take over. With Server Components and Partial Prerendering you can shrink the hydrated portion, but the mental model is still React-first: you’re writing components that may eventually run in the browser.<\/p>\n
Astro flips the default. Pages are static HTML by default and ship zero JS unless you opt in. When you do need interactivity, you wrap a component in a client directive ( Here’s the practical difference. A pricing page with a billing toggle, a region selector, and a small cost calculator. In Next.js, even with Same component: a billing-period toggle that swaps prices.<\/p>\n Next.js App Router version:<\/p>\n That Astro version, with the React renderer installed:<\/p>\n The surrounding I keep reaching for Next.js when the product is an app, not a site. If half the routes need auth, server actions, optimistic UI, and a real database, Astro’s content-first model fights you. Next.js’s Server Actions<\/a> and the way mutations flow through the React tree are still the most ergonomic story I’ve used for full-stack TypeScript work.<\/p>\n I also lean Next.js when I need streaming for a slow-render page. Next.js can stream Suspense boundaries from the edge, and with PPR the static shell renders instantly while the personalized bits load. Astro has server islands now, which is similar, but the Next.js story is more mature and I’ve shipped it more times. I wrote about this in Next.js partial prerendering, six months in production<\/a>. That pattern is hard to replicate cleanly in Astro today.<\/p>\n The team factor matters too. If you’ve got React developers and the cognitive cost of a second framework is real, Astro’s component syntax is close to JSX but it isn’t JSX. The moment you have someone debugging why Finally, I pick Next.js for anything where the routing graph is the product. Dashboards, internal tools, multi-tenant apps. Astro’s file-based routing is fine for content but starts to feel thin compared to App Router’s parallel and intercepted routes.<\/p>\n Content sites. I can’t stress this enough. If the site is mostly text and images, with a handful of interactive bits, Astro’s bundle story is so far ahead it isn’t a fair fight. The home page I ported went from ~280KB of JS to ~14KB. The Lighthouse perf score went from 78 to 99. The build time dropped from 90 seconds to 12.<\/p>\nclient:load<\/code>, client:visible<\/code>, client:idle<\/code>) and only that component hydrates. The rest stays as cold HTML. The Astro docs call this islands architecture<\/a> and it’s the whole point of the framework.<\/p>\n\"use server\"<\/code> directives and aggressive RSC discipline, you’re shipping React’s runtime so those three components can hydrate. In Astro, those three become islands, each can be written in a different framework if you want, and the surrounding marketing copy ships as plain HTML.<\/p>\nA real code comparison<\/h2>\n
\/\/ app\/pricing\/PriceToggle.tsx\n"use client";\n\nimport { useState } from "react";\n\nexport default function PriceToggle({ monthly, yearly }: { monthly: number; yearly: number }) {\n const [annual, setAnnual] = useState(false);\n const price = annual ? yearly : monthly;\n return (\n <div>\n <button onClick={() => setAnnual(!annual)}>\n {annual ? "Billed annually" : "Billed monthly"}\n <\/button>\n <p className="text-3xl">${price}\/mo<\/p>\n <\/div>\n );\n}\n<\/code><\/pre>\n\"use client\"<\/code> pulls in the React runtime for the whole route. You can structure around it, but the cost is real. I’ve seen people forget the directive and then wonder why their interactive component just renders static HTML.<\/p>\n---\n\/\/ src\/pages\/pricing.astro\nimport PriceToggle from '..\/components\/PriceToggle.tsx';\n---\n\n<section>\n <h1>Pricing<\/h1>\n <p>Plain HTML, ships as text.<\/p>\n <PriceToggle client:visible monthly={29} yearly={290} \/>\n<\/section>\n<\/code><\/pre>\n<section><\/code> is HTML. The PriceToggle<\/code> is a React component, but client:visible<\/code> means it only hydrates when it scrolls into view. If a visitor never scrolls there, the React runtime never loads. That’s the part that genuinely changed my mind on Astro for content sites.<\/p>\nWhere Next.js still wins<\/h2>\n
useState<\/code> doesn’t work in a .astro<\/code> file, you’ve lost the win.<\/p>\nWhere Astro actually shines<\/h2>\n