★ 139,925JavaScriptMITupdated Jun 2026
best for the default pick for most new React apps and anyone who wants the biggest ecosystem and hiring pool
Next.js is the one everyone already knows, and for most new React apps that's reason enough. The App Router's React Server Components support is the most production-ready of any framework here — streaming, nested layouts, and server-side data fetching with real caching semantics built in. Turbopack has made dev mode genuinely fast on large codebases, a real change from a year ago.
The catch is the caching model itself. Fetch caching, router cache, full-route cache, and revalidation interact in ways that have burned enough production apps that Vercel has shipped multiple breaking changes just trying to simplify it. Some of the best features — Partial Prerendering, certain middleware behavior — also noticeably work better on Vercel's own hosting than anywhere else, which is hard to read as anything but self-interest. If you want the RSC model without that baggage, TanStack Start is a cleaner slate, though it's earlier and less finished.
Pick Next.js if you want the ecosystem and the hiring pool and are willing to keep up with how fast it moves. The Pages-to-App-Router migration still isn't finished for plenty of teams, which means two different mental models living in one codebase for a while yet.
Our full take →GitHub ↗
★ 60,972TypeScriptMITupdated Oct 2026
best for Vue teams who want the same SSR/data-loading/API-routes package Next.js gives React
Nuxt is what you reach for if your team is already on Vue and wants the same SSR-plus-routing-plus-API-routes package Next.js gives React. The module ecosystem is the real selling point — 300+ modules mean auth, images, and content are usually a config away rather than something you build yourself, which is more than Remix 3 or Vike can offer a Vue team.
Auto-imports make day-to-day coding fast but turn debugging into guesswork for anyone new to the codebase — you'll be grepping for where a composable actually lives more often than you'd like. Major version upgrades have a history of breaking module APIs faster than the ecosystem catches up, so don't assume every module you depend on today survives the next jump cleanly.
The layers underneath — Nitro, the Vite plugin, the kit package — mean a build error can surface three abstractions away from the line that caused it. SvelteKit's adapter model at least isolates that kind of pain to one deploy target at a time.
Our full take →GitHub ↗
★ 33,376TypeScriptMITupdated Sep 2026
best for teams who want nested routing and data loading built on web Request/Response standards instead of a framework-specific abstraction
This isn't the Remix most people know. Remix 3 is a from-scratch rewrite into small, standards-based packages built on fetch, Streams, and Web Crypto instead of Node-specific APIs. That buys something real: the same code runs unmodified on Node, Bun, Deno, and Cloudflare Workers, which none of the Node-rooted frameworks on this page can promise without an adapter layer translating underneath.
The cost is that none of your Remix 2 or React Router knowledge carries over, and it ships under the next dist-tag with no version history or stability notes — you're tracking a moving target, not a release. "Zero dependencies" is a stated goal, not where it is today, so you inherit third-party code with no visibility into which packages those are. Composability also means a real app ends up wiring together a dozen-plus small packages — router, sessions, cookies, middleware — which is more integration surface to vet than Next.js or Nuxt ever ask of you, right when the ecosystem is too new to have found its rough edges.
Our full take →GitHub ↗
★ 20,837JavaScriptMITupdated Oct 2026
best for teams who want a lighter runtime and less boilerplate without giving up SSR or API routes
SvelteKit gets you the same SSR-plus-routing-plus-API-routes shape as Next.js and Nuxt, but on Svelte's smaller runtime, and it treats deployment as genuinely separable: adapter-node, adapter-static, adapter-vercel, and adapter-cloudflare each keep their own changelog and often their own Playwright-tested build, so you're not locked into one hosting story.
The README won't tell you much — it's basically a pointer to the docs site, so plan on living outside the repo for anything beyond how to start a project. A fair number of build problems actually originate in Vite, and SvelteKit's own tracker will bounce you there, so a broken build can mean figuring out which of two projects owns your bug before you can even start fixing it.
Nine packages ship from one monorepo, so a @sveltejs/kit version bump doesn't guarantee your adapter is caught up. Check the adapter's own README before assuming parity, especially for anything outside Node or Vercel.
Our full take →GitHub ↗
★ 14,796TypeScriptMITupdated Jul 2026
best for React teams who want end-to-end type safety on routes and loaders, not just on components
If you've been burned by useSearchParams() handing back string | null and wanted the compiler to actually catch it, this is built for you. Search params get a real schema through Zod or Valibot, and the router itself — not a bolted-on data library — owns loading, caching, and prefetching. No other pick here treats route params as a type problem this seriously.
TanStack Start, the SSR layer on top, is still beta, and there's no React Server Components support — if your team has already invested in the RSC model Next.js encourages, this is a step sideways at best. The generated routeTree.gen.ts file regenerates on every dev server restart and is a steady source of merge conflicts in any monorepo. The Vue and Solid adapters trail React noticeably, with features landing there first and sometimes sitting unported for months, so don't pick this expecting parity outside React.
For a simple SPA it's also just heavier than React Router v6 or Wouter — you'd be paying bundle size for type safety you may not need.
Our full take →GitHub ↗
★ 5,832TypeScriptMITupdated Sep 2026
best for teams who want Next.js-style SSR and file routing but need their own choice of UI library or server
Vike is what you reach for after Next.js's defaults start feeling like a ceiling instead of a convenience. Core routing and SSR are separate from the UI layer — vike-react, vike-vue, vike-solid — so you can swap frameworks without touching your data-fetching or routing model, something none of the React- or Vue-locked picks on this page let you do.
That freedom is also the bill you pay: server framework, data-fetching pattern, and deploy target all become decisions you now have to make, where Next.js or Nuxt would have made them for you. The extension packages mean version-matching across four-plus repos instead of one, trading Next.js's single-package simplicity for exactly the kind of dependency sprawl it was built to avoid.
Worth flagging separately from the framework tradeoffs: Vike's repo ships AGENTS.md and CLAUDE.md files that instruct AI tools to auto-load an external llms.txt URL. That's a prompt-injection-adjacent pattern worth knowing about before you point an agent at this repo unsupervised.
Our full take →GitHub ↗
★ 18,390TypeScriptMITupdated Jun 2026
best for solo devs or small teams who want auth, Prisma, and deploy wired up on day one instead of assembled by hand
Wasp skips the framework-versus-plumbing tradeoff entirely by picking the plumbing for you. Auth, Prisma, background jobs, and type-safe RPC between client and server are declared in a spec file and generated, not assembled by hand. For a solo developer or small team, that's the fastest path from zero to a working app of anything on this list.
The price is flexibility, and it's a real one. You get React Query, Express, and Prisma, full stop — no tRPC instead, no swapping the ORM, and no edge or serverless runtime without rewriting the framework underneath you, unlike Vike or SvelteKit, which are built around letting you choose. It's also been "beta" for years, and the no-lock-in pitch rings a little hollow when your entire app structure lives in a custom spec file that only Wasp understands.
Our full take →GitHub ↗
// questions people ask
Before you choose
Which of these should a new project actually start with?
For most new React apps, Next.js — the ecosystem and hiring pool make it the safe default. If your team is on Vue, Nuxt is the equivalent. Only reach for Vike, TanStack Start, or Remix 3 once you've hit a specific limitation Next.js can't solve.
Is Remix 3 the same framework people used a few years ago?
No. It's a ground-up rewrite with no code or API carryover from Remix 2 or React Router, built on web standards instead of Node APIs. Treat it as a new, beta framework rather than an upgrade path.
What's the safest pick if I don't want to own infrastructure decisions?
Next.js or Nuxt — both make the server, build, and deploy decisions for you. Vike and Remix 3 hand you more control but also more decisions you now have to get right yourself.
Is Wasp a good fit for a larger team or a long-lived product?
Probably not yet. It's been in beta for years, the stack is fixed — React Query, Express, Prisma, no substitutions — and there's no path to edge or serverless runtimes without a framework rewrite. It's strongest for solo projects and early-stage products where speed to a working app matters more than flexibility later.
None of these is wrong, exactly — they trade off control differently, and what's right depends on how much of it you want to hand over. The weekly email flags frameworks like these as they actually mature, instead of leaving you to guess from a changelog.