This is not a framework fight. Next.js is excellent and most of the criticism aimed at it comes from people using it for something it was never meant to do. That is the actual subject here: not which framework is better, but which one matches the shape of the problem.

If your pages are known before the request arrives, you are building a content site. If they cannot be known until someone authenticates, you are building an application. Those want different tools.

The Architectural Difference

Next.js renders React. Even with static generation, the client receives the React runtime and hydrates the tree so the page becomes interactive. That cost is correct when the page is an application, because interactivity is the point.

Astro inverts the default. A page compiles to HTML and ships no JavaScript at all. When a component genuinely needs to be interactive, it becomes an island: that one component hydrates and nothing else does. A service page with a single contact form ships the form’s logic and nothing more.

	Next.js	Amrify (Astro)
Default output	React runtime plus hydrated tree	HTML, no JavaScript
Interactivity model	Whole-page hydration	Per-component islands
UI libraries	React	React, SolidJS, Vue, Svelte, Preact
Content layer	Bring your own	Typed collections, schema-validated
Server needed	For SSR and API routes	None, static output
Failure mode	Runtime error reaches the browser	Build fails before deploy

That last row is worth dwelling on. Content validated at build time means a malformed field breaks the build on your machine, not the page on someone’s phone. Typed collections turn a category of production bug into a category of failed build, which is where you want it.

Where Next.js Is Simply the Right Answer

Use Next.js when:

• You have authenticated users or sessions
• Pages depend on per-request data
• You need API routes, server actions or middleware
• You are building a product, not publishing pages
• Your team’s React expertise is the main asset and the site is genuinely an app

None of that is a concession. If you are building a dashboard, the whole argument on this page is irrelevant to you.

Where the Overhead Stops Paying

Use something static when:

• Every page is known at build time
• The site is marketing, service pages, docs or a blog
• Core Web Vitals matter commercially, because you compete in search
• You would rather not run a server for pages that never change
• You are maintaining many similar sites, which is the next section

The Multi-Site Problem

This is the part that decides it for agencies, and it rarely appears in framework comparisons because it is an operations problem rather than a technical one.

Fifteen client sites built independently in Next.js usually means fifteen repositories, fifteen dependency trees, and fifteen upgrade paths that drift apart the moment nobody has time. A security advisory lands and it is fifteen pull requests. A client asks for a change to a shared pattern and it is fifteen implementations that were each slightly different to begin with.

The Amrify boilerplate is one monorepo with shared packages, and the license covers unlimited sites. Components, schema builders, layouts and config loaders live once. A fix to the contact form is one commit that every site inherits on its next build.

We are not describing this from theory. Thirty sites run this way in a single repository, which is what makes a $249 one-time price for the whole system arithmetically possible: the engineering was written once.

Build Times and Day-to-Day Work

Static generation gets cheaper as the framework does less. Astro is not compiling a React tree for pages that contain no React, so build times track the number of pages rather than the weight of the runtime.

The practical difference for an agency is not the seconds saved. It is that a content edit is a text file, so a non-developer can make it without touching a component, and a broken edit fails the build rather than shipping. That moves routine content work off the developer’s desk, which is usually where the real cost was hiding.

Search

Both frameworks can rank. Next.js static generation produces crawlable HTML and Google renders JavaScript competently these days. The differences are narrower than partisans on either side suggest.

The gap that remains is Core Web Vitals under real conditions. Hydration costs main-thread time, and main-thread time on a mid-range phone on mobile data is where Interaction to Next Paint is won or lost. Shipping no runtime is a structural advantage that no amount of optimisation on the other side fully closes, because the fastest JavaScript is the JavaScript you never sent.

Structured data, sitemaps, canonical URLs and metadata are generated from typed content here rather than assembled per page, so they stay correct as the site grows instead of drifting.

What You Give Up

An honest comparison has to include this, because every architectural choice costs something.

You give up per-request rendering. If a page must reflect data that changed a second ago, static output is the wrong shape and you will end up bolting on client-side fetching, at which point you have reinvented the thing you avoided.

You give up the React ecosystem as a default. Islands support React, but a library that assumes it owns the whole page and mounts a global provider tree will fight the model. Component libraries designed around context providers are the usual friction point.

You give up familiarity, which is a real cost on a team. Astro’s template syntax is close to JSX but not identical, content collections are a different mental model from filesystem routing plus MDX, and the first week is slower. That is a genuine expense even though it amortises.

And you give up server-side anything. No API routes, no middleware, no server actions. For a marketing site that is a feature, because there is no server to secure or scale. For anything with accounts it is disqualifying.

Migrating an Existing Next.js Content Site

If the site is already static, the move is mostly mechanical rather than a rewrite.

Pages become content entries. MDX files carry over with frontmatter adjusted to match a typed collection schema, which is usually where the real work sits, because the schema surfaces every field that was optional in practice but assumed everywhere in the templates.

Components port in tiers. Anything purely presentational becomes an Astro component and loses its runtime entirely. Anything genuinely interactive stays React and becomes an island with an explicit hydration directive. The useful discipline is that you now have to justify each one, and most teams find the list is shorter than they assumed.

Routing maps closely, since file-based routing works the same way in both. Dynamic routes become getStaticPaths, which most Next.js content sites were already using.

The step that matters commercially is the same as any migration: every URL that changes needs a 301 to its replacement. Rankings follow URLs, and a clean architecture migration that drops the redirect map is still a traffic loss.

Proof You Can Check

We do not publish customer testimonials. We had some, they turned out to be fabricated, and we removed them.

What we can point at is the fleet. Live production sites on this architecture:

• Express Mounting, TV mounting, Atlanta
• Glass Inc, auto and residential glass
• Best Alpharetta Roofer, roofing
• Alexus Pressure Washing, exterior cleaning

Run any of them through PageSpeed Insights, or read the HTML and count the script tags. Both are more useful than a quote from someone you cannot verify exists.

Built and maintained by Alex Crabinsky, a full-stack developer with over ten years building production websites.

Common Questions

Is Next.js bad for content sites?

No, it is more machinery than the job needs. That is a real cost, not a moral failing.

Can I keep using React?

Yes, as islands. Use it where interactivity earns the runtime, and ship HTML everywhere else.

What about API routes and auth?

Use Next.js. If the product needs a server, use a framework built around having one.

Can I try it without committing?

The fleet sites above are live and inspectable: run them through PageSpeed Insights or read their HTML and count the script tags. The docs describe exactly what is in the repository before you buy.

---

Match the tool to the shape of the problem. Read the docs, or see pricing for the founding offer on the full monorepo.