Key takeaway: Pick Next.js when the brief is an application that happens to have content, not a content site that happens to have a form. Static export works, but it switches off most of what you are carrying the framework's weight for. For pure content, Astro ships less JavaScript and takes less configuring to get there.
Quick facts
- LanguageTypeScript
- CategoryReact-based
- LicenseMIT
- Created2016
- GitHub stars134k
- Statusactive
Templating: JSX TSX Markdown MDX
What it is
Next.js is the most-used React framework on the planet. Static export is supported (output: "export") but Next.js really wins as a full app framework, App Router, Server Components, Server Actions, ISR. Listing it as an SSG is a stretch in 2026; most production Next.js deploys are SSR + ISR + edge.
Best for
- Application-shape briefs where dynamic routes, auth, real-time matter
- Hybrid sites mixing static marketing with authenticated dashboards
- Teams already on React
- Workloads that benefit from on-demand ISR (revalidate by tag)
When not to pick it
Skip Next.js for purely static content sites where Astro will be cheaper to run, smaller bundle, and faster to ship. Also skip it for tiny sites where the framework overhead beats the build benefit.
My take
Next.js is the right answer for application-shape work and the wrong answer for pure SSG. Use the right tool for the brief, both Vercel and the Next.js team have said the same thing in interviews.
Static export versus the App Router default
Next.js can emit a fully static site with output set to export, and for a small marketing site that genuinely works. What you give up is most of what makes Next.js worth choosing: no incremental regeneration, no middleware, no Server Actions, no on-demand revalidation, route handlers reduced to static GET responses, and the built-in image optimiser needing a custom loader or a third-party CDN. The static path is the least interesting version of the framework. The App Router is where the team's effort goes, and it assumes a server: Server Components fetch at request time, Server Actions mutate, and caching is decided per route rather than all or nothing. If you are choosing Next.js because you want static HTML, you are adopting a large application framework and then turning most of it off. Astro gets you the same HTML with a fraction of the client bundle and nothing to disable.
Upgrade cadence and where it actually runs
Next.js is MIT licensed and runs anywhere Node runs, but the smooth path is Vercel and features land there first. Self-hosting a Node server is well documented; getting equivalent behaviour on Cloudflare or AWS usually means an adapter project maintained outside the core team, which is one more dependency to keep current. The larger operational cost is churn. Next.js moves quickly, and the App Router rewrote the mental model for data fetching, caching, and layouts. A codebase you leave untouched for a year and a half will not upgrade in an afternoon. That is a fair trade when you are shipping an application and want new React capabilities early. It is a poor trade for a brochure site that will not change until the next rebrand, which is precisely the case for Astro, Eleventy, or Hugo instead.
Frequently asked questions
Can Next.js generate a fully static site?
Yes. With static export it prerenders every route to HTML and writes a folder you can host anywhere. The catch is what stops working: incremental regeneration, middleware, Server Actions, and the default image optimiser all go away, and route handlers are limited to static GET responses. You end up running a large framework with most of it disabled. For a purely static site, Astro or Eleventy is a lighter fit.
Next.js or Astro for a marketing site?
Astro, in most cases. It ships no client JavaScript unless you ask for it, so Core Web Vitals start good rather than needing remediation, and there is nothing to switch off. Choose Next.js when the marketing pages share a codebase with an authenticated app, or when the team is already deep in React and consolidating on one framework outweighs the bundle savings.
Do I have to deploy Next.js on Vercel?
No. It is MIT licensed and a standard Node server deployment is supported and documented. Vercel is where new features get exercised first and where defaults line up without effort, so other targets sometimes lag or depend on community adapters. Budget time for that if you are committing to Cloudflare, AWS, or your own containers rather than the first-party path.
Links
Compare Next.js side-by-side
Similar tools you should also consider
If Next.js is your pick, the next conversation is short
The 30-min call is where your project gets a real architecture, an SEO transport plan, and a price range you can take to your team. Describe your site, your timeline, your existing content. I tell you whether Next.js is genuinely the right call for you, and what the build actually looks like.