Framework Landscape
Ten frameworks can deploy to Cloudflare Workers. They differ in rendering strategy, Cloudflare integration depth, and what problems they solve. Here’s how to think about the landscape.
The Three Tiers
flowchart LR
subgraph tier1["Tier 1: CF Vite Plugin"]
RR[React Router v7]
TS[TanStack Start]
AS[Astro v13]
SPA[Vite + React SPA]
end
subgraph tier2["Tier 2: Adapter-Based"]
SK[SvelteKit]
NX[Nuxt]
QC[Qwik City]
SS[SolidStart]
end
subgraph tier3["Tier 3: Compatibility"]
NJ[Next.js via OpenNext]
HO[Hono]
end
tier1 -->|"workerd in dev"| WD[Cloudflare Workers]
tier2 -->|"Node.js in dev"| WD
tier3 -->|"shims or native"| WD
Tier 1: Native Cloudflare Integration
These frameworks use the Cloudflare Vite Plugin for full dev/prod parity. Server code runs in workerd during development, so you catch runtime issues before deploying.
| Framework | UI Library | SSR | CF Vite Plugin |
|---|---|---|---|
| React Router v7 | React | Yes | Yes |
| TanStack Start | React | Yes | Yes |
| Astro | Any (islands) | Yes | Yes (adapter v13) |
| Vite + React SPA | React | No | Yes (static assets) |
Tier 2: Adapter-Based Integration
These frameworks have Cloudflare adapters but don’t use the CF Vite Plugin. Dev runs in Node.js; prod runs in workerd. You may hit edge-only issues after deploying.
| Framework | UI Library | SSR | Adapter |
|---|---|---|---|
| SvelteKit | Svelte | Yes | adapter-cloudflare |
| Nuxt | Vue | Yes | nitro-preset-cloudflare |
| Qwik City | Qwik | Yes | @builder.io/qwik-city/adapters/cloudflare-pages |
| SolidStart | Solid | Yes | cloudflare-pages preset |
Tier 3: Compatibility Layer
These work on Cloudflare but with caveats.
| Framework | UI Library | SSR | How |
|---|---|---|---|
| Next.js | React | Yes | OpenNext adapter (Node.js API shimming) |
| Hono | None | API only | Native Worker, no built-in UI rendering |
Decision Factors
Do you need SSR?
If no: use Vite + React SPA or Astro (static mode). Deploy as static assets to Workers. Zero cold starts, simplest setup.
If yes: pick based on your UI library preference and how deep you need Cloudflare integration.
Which UI library?
React -> React Router v7 (default) or TanStack Start (type-safe routing)
Svelte -> SvelteKit
Vue -> Nuxt
Solid -> SolidStart
Any/None -> Astro (content) or Hono (API)
Do you need Cloudflare bindings in dev?
Bindings are KV, D1, R2, Durable Objects, Queues, AI, etc. If your app uses them heavily, you want the CF Vite Plugin for real workerd execution during dev.
- CF Vite Plugin (Tier 1): Bindings work in dev exactly like prod
- Adapters (Tier 2): Use
wrangler typesto generate types, but dev hits Node.js shims orgetPlatformProxy() - OpenNext (Tier 3): Bindings accessible but dev runs Node.js entirely
Are you migrating from Next.js?
Two paths:
- Keep Next.js: Use OpenNext adapter. Supports App Router, Pages Router, RSC, ISR, streaming, Server Actions. Main cost is no
workerddev parity. - Switch frameworks: React Router v7 is the closest React-based alternative with first-class Cloudflare support.
Quick Recommendation
Building something new on Cloudflare?
├── Content site -> Astro
├── Full-stack React -> React Router v7
├── Type-safe React -> TanStack Start
├── API/microservice -> Hono
├── Svelte app -> SvelteKit
├── Vue app -> Nuxt
├── Static SPA -> Vite + React
└── Migrating from Next -> OpenNext (keep) or React Router v7 (switch)
Tip:
npx wrangler deployauto-detects your framework and handles adapter installation. You don’t need to configure everything manually.
What About Remix?
Remix is dead. Cloudflare’s docs explicitly say it’s “no longer recommended for new projects.” React Router v7 is its successor and handles everything Remix did, with better Cloudflare integration.
What About “VitePlus” or “Vite+”?
This is not a real product. If you’ve seen it referenced, it likely refers to the Cloudflare Vite Plugin (@cloudflare/vite-plugin) or the general pattern of “Vite plus framework-specific plugins.”