People ask us this a lot, usually phrased as “which one is better.” Wrong question. We shipped FurnitureAxis on Next.js and this site on Astro, in the same year, with the same team. Neither choice was a default. Here is the actual reasoning, not a spec sheet.
What FurnitureAxis needed
FurnitureAxis is a multi-tenant SaaS for furniture retailers: quotes, serialized inventory across warehouses, purchase orders, delivery scheduling, commissions. It’s built on Next.js 15 with React 19, Prisma, and PostgreSQL, and the schema has grown past a hundred models as the product deepened.
Every screen in that product is behind a login and scoped to one tenant’s data. A warehouse manager and a sales rep looking at the same URL see different numbers, because the numbers depend on who’s asking. That’s the opposite of a page you can render once and cache: the server has to know who you are before it knows what to send back.
Next.js’s App Router pairs React Server Components with Server Actions, so a form on a product page can call server code directly, without us hand-rolling a separate API route for every mutation. Inventory adjustments, order creation, commission recalculation: all of it goes through a small number of typed server functions that live next to the components that call them. For a hundred-plus-model app with constant writes, that’s not a nice-to-have. It’s the difference between one codebase and two that have to agree with each other.
What this site needed
Dawloom.com is a marketing site with a blog. Nobody logs in. The homepage you see is the homepage everyone sees, which means it can be built once and handed to a CDN instead of rebuilt on every request.
We built it in Astro, and the site runs as static output on Cloudflare Workers, currently scoring around 97 on Lighthouse’s mobile performance check. We wrote about the specific build decisions behind that number in why this site loads in under a second. The short version: almost the entire site is HTML with no JavaScript framework attached to it.
The actual difference
Astro’s islands architecture renders a page to static HTML by default and only ships JavaScript for the components you explicitly mark as interactive. On this site that’s one Svelte component, the mascot, and it loads after the page goes idle. A details element handles the FAQ accordions. No framework needed for that.
Next.js takes the opposite default. Server Components render to HTML on the server, but Client Components ship their JavaScript to the browser so React can hydrate them and keep responding to clicks, keystrokes, and state changes after the page loads. That’s exactly what an authenticated app needs: a data table that filters without a page reload, a form that revalidates without a full navigation. It’s also work a static content page doesn’t need to pay for.
Neither approach is more advanced than the other. They’re solving different problems. A content site doesn’t have client state to hydrate because there’s no client state; a SaaS dashboard has nothing but client state, updated per user, per session, per click.
How we choose
We don’t run a scoring matrix. We ask one question: does this page need to know who’s asking before it can respond?
If the answer is no, meaning the content is the same for every visitor and the job is to get words and images in front of people as fast as possible, we reach for Astro. Marketing sites, blogs, documentation, anything where search ranking and AI-assistant readability matter more than client interactivity.
If the answer is yes, meaning the page renders differently per user, holds form state, or triggers server mutations on click, we reach for Next.js. SaaS products, dashboards, anything with a login wall and data that changes underneath it.
The edge cases are real and we don’t pretend otherwise. A SaaS product still needs a marketing site in front of it, and that front page is usually better off static, sometimes even a separate Astro build that links into the Next.js app at the login wall. A content site that grows a members’ area is a sign the content site is turning into a product, and that’s the point where Astro stops being the right tool for the new part.
What we won’t do is default to one framework because it’s the one we know best or the one that’s trending. We picked Next.js for FurnitureAxis because the product is a hundred-plus-model SaaS with per-tenant mutations happening constantly. We picked Astro for our own site because it’s a blog with a contact form. Using Next.js here would mean shipping a React runtime to render text that never changes. Using Astro for FurnitureAxis would mean rebuilding server actions, auth-aware rendering, and per-tenant data fetching that the framework already gives us.
If you’re building something and aren’t sure which side of that line it falls on, that’s a conversation worth having before any code gets written. Tell us what you’re building and we’ll tell you honestly which one it needs, even if the answer isn’t the framework we’d personally rather write in.