This is part of an ongoing series I am writing as I work my way through the modern web stack from a WordPress developer’s perspective. The series is aimed at WordPress veterans who, like me, have built things on the web for years and feel quietly behind the curve. The goal is broad literacy, not deep mastery. By the end you should be able to read any modern stack list and know what each piece is doing.
Each post comes with an audio companion (10-15 minutes, generated via NotebookLM) for gym or commute listening. Press play below if that suits you better than reading.
Hook
Reaching for Next.js on every project is the modern web equivalent of installing WordPress on every domain you own. It is the default for a reason, and most of the time it works fine, but when a project does not fit the default it really does not fit. The same way a brochure site does not need WP Multisite, a marketing site for one product does not need server components and edge functions and a deploy preview pipeline.
This module is the counterweight to the last one. When is Next.js the wrong answer, what should you reach for instead, and how do the alternatives differ from each other once you look past the marketing pages?
The honest version: most “Next.js for everything” people have not actually shipped two of the alternatives in production. Most “Next.js is bloated” people have not shipped Next.js in production either. Both takes are louder than useful. The real answer is project-shape-dependent.
Core Concept
Modern web frameworks differ on three axes. Once you can name the axes, picking between frameworks stops feeling like fashion.
How much JavaScript ships to the browser. Some frameworks try to ship the minimum: a static HTML page with tiny islands of interactivity where needed. Others assume the browser is the application platform and ship a full client-side app. Astro is on the minimum-ship end. Next.js sits in the middle (server components first, client islands when needed). A traditional single-page React app at Vite is on the maximum-ship end.
Where the data fetching happens. Some frameworks default to the server (Next.js App Router, Astro, SvelteKit). Some default to the client (Vite SPAs, traditional React with React Router). Server-default frameworks tend to be better for SEO and initial load. Client-default frameworks tend to be better for highly interactive applications where the page never really reloads.
How tightly coupled the framework is to a particular host. Next.js leans hard toward Vercel. Some features only work well there. SvelteKit and Astro deploy to almost anything with adapters. Vite-based apps deploy to any static host.
If you internalise those three axes, picking the right framework is mostly a matter of placing your project on each one.
When NOT to Use Next.js
A few honest cases where another framework will save you time and frustration.
Content-heavy Site with Light Interactivity → Astro
Marketing sites, documentation, blogs, brochure sites with a contact form. If the page is mostly content with the occasional interactive widget, Astro ships the minimum JavaScript possible and gets out of your way. You can still use React components inside Astro when you need interactivity. The framework picks them up and ships them as islands. Less JavaScript, faster pages, simpler deploy.
The mental model: Astro is “static HTML with interactive sprinkles.” Next.js is “interactive app with static parts where it makes sense.” For most jeangalea-shaped personal blogs, Astro is the better fit.
Highly Interactive App with No SSR Needs → Vite + React Router
If you are building a tool, dashboard, or internal app that lives behind a login and does not need to be indexed by search engines, you do not need Next.js. A plain Vite project with React Router gives you a faster dev server, simpler builds, and total control over deployment. No server components to wrap your head around. No App Router conventions to follow.
This is the sweet spot for “single page application” style apps. Many ex-Create-React-App projects landed here.
Form-heavy CRUD App on a Small Team → React Router 7
Remix merged into React Router 7 in late 2024. The combined framework keeps Remix’s strengths: nested routing, form-based mutations, progressive enhancement, server-side data loaders. It is less “let us reinvent how React works” than Next.js and more “give me sensible defaults for the web platform.”
If your project is structured around forms, server actions, and traditional request-response patterns rather than around an SPA-style interactive UI, React Router 7 is genuinely competitive with Next.js. The bundle sizes tend to be smaller. The mental model tends to feel cleaner if you are coming from server-rendered PHP.
Smaller Bundle, Simpler Reactivity → SvelteKit
If you are starting fresh and have no React baggage, SvelteKit is worth a real look. Svelte the language compiles components to plain JavaScript at build time, with no virtual DOM overhead. Final bundles are dramatically smaller. The reactivity model is simpler than React’s hooks. Developer ergonomics are quietly excellent.
The catch: smaller ecosystem, fewer pre-built integrations, fewer hireable developers. For a personal project or a team that loves the language, SvelteKit is delightful. For “this needs to run for ten years and survive turnover,” React’s gravity still matters.
Vue-centric Team → Nuxt
If your team already does Vue (and many WordPress shops fell into Vue rather than React because of how Vue feels closer to “templates and reactivity” than React’s “everything is JavaScript”), Nuxt is the Vue equivalent of Next.js. Same shape: file-based routing, server components, server-side rendering, static generation. Different language. If you are already in the Vue world, do not switch frameworks unless you have a strong reason.
Just Learning React → Vite + React, No Meta-framework
This is a real one. If you are picking up React for the first time, dropping into Next.js is like learning to drive in a sports car. Too much going on at once. Server components, client components, routing conventions, build pipelines, all on day one. Start with npm create vite@latest and learn React on its own. Add React Router when you need routing. Add a meta-framework when you understand what one would give you.
The WordPress Analogue
Mental model: Next.js, Astro, SvelteKit, Nuxt and friends are to React/Vue what WordPress, Drupal, Craft, and Statamic are to PHP CMSes.
They share the same underlying language and a lot of the same patterns. They differ on what they optimise for, what conventions they enforce, and how loud their communities are. Picking between them is rarely about technical superiority. It is about which set of opinions matches your project shape. PHP developers have known this for fifteen years. React developers are slowly learning it.
The Landscape
A quick comparison table of the main alternatives:
| Framework | Best for | Default JS shipped | Routing | Deploy |
|---|---|---|---|---|
| Next.js | Full apps, hybrid sites | Medium (server components + client islands) | File-based, App Router | Vercel-leaning, works elsewhere |
| Astro | Content sites, blogs, docs, marketing | Minimal (zero by default) | File-based | Anywhere (static or SSR adapter) |
| React Router 7 | Form/CRUD apps, server-rendered React | Medium | Nested route configuration | Node-anywhere |
| SvelteKit | Smaller bundles, simpler reactivity | Tiny | File-based | Anywhere with adapter |
| Nuxt | Vue equivalent of Next.js | Medium | File-based | Anywhere with adapter |
| Vite + React + Router | Pure SPA, internal tools, learning | All client-side | Router config | Any static host |
| TanStack Start | Newer, type-safe, full-stack TS apps | Medium | TanStack Router | Anywhere |
The honest take: 70 percent of projects can be done in Next.js without anyone regretting it. Maybe 20 percent are clearly better served by Astro. The remaining 10 percent is where the other frameworks shine, and picking the right one is genuinely worth the time.
What This Changes for WordPress People
Three practical implications.
The first is your default reach for client work shifts. For a brochure site, marketing site, or content-heavy project where WP would have been the default ten years ago, Astro is now a serious contender. Faster pages, simpler deploy, no plugin updates to babysit. Clients with content editors still need a CMS, but you can pair Astro with a headless CMS (covered in a later module) and get the best of both worlds.
The second is “Next.js” stops being a yes-or-no choice and becomes “Next.js or what?” Once you can name the alternatives and what each is for, your conversations with clients and developers get sharper. “We chose Astro because the site is 95 percent static and we wanted minimum JavaScript” lands very differently than “We are using Next.js because it is popular.”
The third is your hiring filter improves. A frontend developer who only knows Next.js is more common than one who can pick the right framework for the job. If you ever hire for a client project, asking “when would you reach for Astro instead?” is a fast way to separate confident developers from cargo-culters.
Watch Out
A few traps when evaluating alternatives.
Smaller ecosystems mean more “write it yourself.” Next.js has a Stripe template, a Supabase template, an Auth.js template, dozens of pre-built starter kits. SvelteKit and Astro have fewer. For a side project this is fine. For a production app on a deadline, it can add a week.
Vercel works with all of them, but optimises for Next.js. Astro, SvelteKit, and Nuxt deploy to Vercel just fine. But the deeper Vercel features (image optimisation, ISR, edge middleware) are Next.js-specific. If you are picking a non-Next framework partly to escape Vercel lock-in, double-check that the platform actually supports the framework you chose.
The React Router 7 / Remix migration is real but bumpy. If you are reading content from before 2024 that talks about Remix, mentally rename it to React Router 7. Most of the patterns survived. Some import paths changed. The framework is solid; the rename has created some confusing docs.
“Lighter is faster” is not always true. Astro pages are smaller and faster on first load, but if your app needs heavy client-side interactivity, you will end up shipping more JavaScript anyway. The framework that ships less JS is not automatically better; it is better for projects whose interactivity needs are genuinely modest.
Beware framework benchmarks. Every framework has a benchmark page showing it beats the others. They all use slightly different methodology. None of them reflects what your actual project will look like. Use frameworks because they fit your project, not because they win a synthetic test.
Going Deeper
If you want to develop real opinions about when to reach for what, a few resources.
YouTube, gym or commute friendly:
- “Picking a JavaScript Meta-Framework in 2025” by Theo (t3.gg, ~45 min). Opinionated but knowledgeable. Frames the alternatives the way most professional devs do internally.
- “Astro vs Next.js” by Web Dev Simplified (~20 min). Concrete comparison that focuses on real project differences, not marketing claims.
Official docs worth a skim:
- Astro docs. The “Why Astro” page is one of the better framework-pitch docs around.
- React Router docs. Now covers what used to be Remix. Start with the tutorial.
- SvelteKit docs. Read the intro pages even if you do not plan to use it; the philosophy section sharpens how you think about frameworks generally.
Next post in the series leaves the frontend behind and looks at the modern database layer: Supabase, Neon, PlanetScale, Turso, and what changes when your MySQL stops living next to your code.
Related
Leave a Reply