What is the difference between Astro and Next.js?

The main difference between Astro and Next.js is what each one assumes about your pages. Astro assumes most of a page is static content: it renders HTML on the server, sends no JavaScript by default and lets you hydrate individual components as islands, using React, Vue, Svelte or no framework at all. Next.js is a React framework that assumes you're building an application: every page is a React tree, and even with Server Components it ships the React runtime and a client-side router so that navigation and interactivity work as a single-page app. Astro is optimised for content-driven websites; Next.js is optimised for interactive, React-based web applications.

Both are excellent, both render on the server and both can produce static files. The differences show up in how much JavaScript reaches the browser, how you write components and how you handle data and caching. In this article you'll learn how the two compare on architecture, components, routing, data fetching, caching, deployment and performance, with the same page built in each, and a practical way to decide. The comparison uses Astro 7.4.2 and Next.js 16.

The Short Version

	Astro 7	Next.js 16
Primary focus	Content-driven websites	React web applications
UI framework	Any (React, Vue, Svelte, Solid, Preact, Alpine) or none	React only
Default JavaScript	None	React runtime and router on every page
Interactivity model	Client islands (client:* directives)	Client Components ('use client') inside a React tree
Navigation	Full page loads (MPA), optional <ClientRouter />	Client-side router with prefetching
Default rendering	Prerendered at build time	Prerendered where possible, dynamic when needed
Content tooling	Content collections with schemas, Markdown, MDX	Bring your own (MDX support via plugin)
Server mutations	Actions (astro:actions), API endpoints	Server Functions ('use server'), Route Handlers
Bundler	Vite 8	Turbopack (default)
Hosting	Static host, or adapters for Node, Vercel, Netlify, Cloudflare	Node.js server, Docker, static export, adapters

Rendering Model: Islands vs Server Components

This is the heart of it.

How Astro Renders

An Astro page is a template that runs on the server. Its output is HTML. Framework components inside it are rendered to HTML too, and their JavaScript is dropped unless you add a directive:

---
// src/pages/blog/[slug].astro
import LikeButton from '../../components/LikeButton.jsx';
import { posts } from '../../lib/posts';

export function getStaticPaths() {
  return posts.map((post) => ({ params: { slug: post.slug }, props: { post } }));
}

const { post } = Astro.props;
---
<article>
  <h1>{post.title}</h1>
  <LikeButton likes={post.likes} client:visible />
</article>

Here, only LikeButton becomes interactive, and only when it scrolls into view. The heading and article are plain HTML that never involve React in the browser. You can learn more in how Astro's island architecture works.

How Next.js Renders

In the Next.js App Router, pages and layouts are React Server Components by default. You mark interactive components with 'use client':

// app/ui/like-button.js
'use client';
import { useState } from 'react';

export default function LikeButton({ likes }) {
  const [count, setCount] = useState(likes);
  return <button onClick={() => setCount(count + 1)}>{count} likes</button>;
}

// app/blog/[slug]/page.js
import LikeButton from '../../ui/like-button';
import { posts, getPost } from '../../../lib/posts';

export async function generateStaticParams() {
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function Page({ params }) {
  const { slug } = await params;
  const post = await getPost(slug);
  return (
    <article>
      <h1>{post.title}</h1>
      <LikeButton likes={post.likes} />
    </article>
  );
}

Server Components don't send their own code to the browser, which is a big improvement over older React frameworks. But the page is still a React application. Next.js sends HTML for the first paint, a React Server Component payload describing the tree, and the JavaScript needed to hydrate Client Components. React, the Next.js runtime and the router load on every page so that later navigations can happen on the client using prefetched payloads.

So both frameworks have a "server part" and a "client part", but the defaults differ. In Astro, the browser runtime is opt-in per component. In Next.js, the runtime is always there and you opt in to client-side code per component.

How Much JavaScript Each Ships

To make this concrete, I built a page with a heading and a short list of links, with no interactive components at all, in both frameworks and measured the JavaScript each page references:

Build	JavaScript files	Size (gzipped)
Astro 7.4.2, static output	0	0 KB
Next.js 16.4.3, output: 'export'	5, plus a noModule polyfill that modern browsers skip	about 135 KB

Adding one React island to the Astro page brings it to about 69 KB, almost all of which is React DOM, and the island can be deferred with client:visible or client:idle. With Preact, Svelte or a plain <script>, it's far smaller.

Those 135 KB aren't wasted in Next.js: they buy instant client-side navigation, shared layouts that persist between pages and React state that survives route changes. If you need those things, you'd add similar code to an Astro site anyway. If you don't, Astro lets you skip it. Read more in how Astro ships zero JavaScript by default.

Components and Syntax

Astro components use an HTML-first syntax with a script block at the top:

---
// src/components/Card.astro
interface Props {
  title: string;
  href: string;
}

const { title, href } = Astro.props;
---
<article class="card">
  <h2><a href={href}>{title}</a></h2>
  <slot />
</article>

<style>
  .card { padding: 1rem; border: 1px solid #ddd; }
</style>

Key differences from React and JSX:

• Standard HTML attributes: class, for and kebab-case data-* attributes, not className.
• No re-rendering: an Astro template runs once on the server. There's no state, no hooks and no effects to think about.
• Slots instead of children props: <slot /> and named slots place child content.
• Scoped styles: a <style> tag is scoped to the component automatically.
• Mix frameworks: an .astro file can render React, Svelte and Vue components side by side.

Next.js components are React components, full stop. If your team already thinks in React, Next.js has no new syntax to learn. If your team includes people who mostly write HTML and CSS, Astro is usually easier to pick up. For more detail, see what .astro files are and how they work.

Routing

Both use file-based routing, with different conventions:

	Astro	Next.js (App Router)
Pages folder	src/pages/	app/
Page file	src/pages/about.astro	app/about/page.js
Dynamic route	src/pages/blog/[slug].astro	app/blog/[slug]/page.js
Static params	getStaticPaths()	generateStaticParams()
Catch-all	[...path].astro	[...path]/page.js
API route	src/pages/api/hello.ts exporting GET	app/api/hello/route.js exporting GET
Shared layout	A layout component you import	layout.js, applied automatically and persisted
Request interception	src/middleware.ts	proxy.js (renamed from Middleware in Next.js 16)

Next.js has richer routing primitives for applications: nested layouts that persist across navigations, loading and error boundaries per segment, parallel and intercepting routes. Astro layouts are just components, which is simpler but means each navigation renders a fresh document. Astro 7 also enables advanced routing by default, with src/fetch.ts as a reserved file for configuring it.

Data Fetching and Content

In both frameworks you can await data directly on the server. In Astro, that happens in the component script; in Next.js, inside an async Server Component.

Where Astro pulls ahead for websites is content collections. You define a collection with a loader and a Zod schema in src/content.config.ts, and Astro validates every Markdown, MDX, JSON or YAML entry at build time, generates TypeScript types and gives you getCollection() and render():

// src/content.config.ts
import { defineCollection } from 'astro:content';
import { glob } from 'astro/loaders';
import { z } from 'astro/zod';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    pubDate: z.coerce.date(),
  }),
});

export const collections = { blog };

Loaders can also pull from a CMS or API at build time, and live collections fetch on each request. Next.js leaves content handling to you: you can read files, use MDX via @next/mdx or call a CMS, but there's no built-in schema validation or content layer. The Astro content collections guide goes further.

Caching and Dynamic Pages

Both frameworks let you mix static and dynamic pages, but they approach caching differently.

• Astro prerenders every page by default. With an adapter installed, you set export const prerender = false on pages that must render per request, or switch to output: 'server' and opt individual pages back into prerendering. Astro 7 adds stable route caching through top-level cache and routeRules config, and server islands let you keep a cached page with small dynamic pieces.
• Next.js prerenders what it can and makes routes dynamic when they use request data. With Cache Components enabled (cacheComponents: true), you mark functions or components with the 'use cache' directive, set lifetimes with cacheLife() and invalidate with revalidateTag(), updateTag() or revalidatePath(). Uncached async work is wrapped in <Suspense> and streamed into a prerendered shell.

Next.js's model is more granular and more powerful for applications whose data changes constantly. Astro's model is simpler to reason about: a page is either built ahead of time or rendered on request.

Mutations and Forms

For writes, Next.js has Server Functions marked with 'use server', which can be passed straight to a form's action prop. Astro has Actions, defined in src/actions/index.ts with defineAction() and called from forms, scripts or framework components through the actions object from astro:actions. Both also support plain API endpoints. The ergonomics are similar; Next.js integrates more tightly with React's transitions, while Astro's actions work without any UI framework.

Deployment

Astro builds to a folder of static files by default, so any static host works: Netlify, Vercel, Cloudflare, GitHub Pages, S3 or your own Nginx server. For on-demand rendering you add an adapter; official ones exist for Node.js, Vercel, Netlify and Cloudflare.

Next.js supports all of its features on a Node.js server or in a Docker container, a limited feature set with output: 'export', and other platforms through adapters. It's developed by Vercel, which has the deepest integration, but self-hosting is fully supported.

When to Choose Each

Choose Astro when:

• The site is mostly content: blogs, documentation, marketing pages, publications, portfolios.
• Performance and SEO are top priorities, and you want them without tuning.
• You want framework freedom: use React for one widget and Svelte for another, or no framework.
• Your content lives in Markdown, MDX or a CMS and benefits from schemas and types.

Choose Next.js when:

• You're building an application: dashboards, SaaS products, social features, anything with lots of shared client state.
• Navigation should feel app-like, with persistent layouts and client-side transitions everywhere.
• Your team is all-in on React and wants one model for everything.
• You need fine-grained caching and streaming across many dynamic data sources.

Many organisations use both: Astro for the marketing site and docs, Next.js for the logged-in product. For the edge cases where Astro is the wrong tool, see when you should not use Astro.

---

FAQ: Astro vs Next.js

---

Conclusion

Astro and Next.js both render on the server, but they start from opposite assumptions. Astro treats a page as HTML and makes interactivity an opt-in, per-component decision, which is why a content page can arrive with no JavaScript. Next.js treats a page as part of a React application, using Server Components to keep server code out of the bundle while still giving you a client-side router, persistent layouts and granular caching.

If you're publishing content, Astro is the simpler and faster default. If you're building a product where most of the screen is interactive and React is already your language, Next.js is the more natural fit. Measure the JavaScript each page ships and the choice usually becomes obvious.