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.

FrameworkUI LibrarySSRCF Vite Plugin
React Router v7ReactYesYes
TanStack StartReactYesYes
AstroAny (islands)YesYes (adapter v13)
Vite + React SPAReactNoYes (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.

FrameworkUI LibrarySSRAdapter
SvelteKitSvelteYesadapter-cloudflare
NuxtVueYesnitro-preset-cloudflare
Qwik CityQwikYes@builder.io/qwik-city/adapters/cloudflare-pages
SolidStartSolidYescloudflare-pages preset

Tier 3: Compatibility Layer

These work on Cloudflare but with caveats.

FrameworkUI LibrarySSRHow
Next.jsReactYesOpenNext adapter (Node.js API shimming)
HonoNoneAPI onlyNative 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 types to generate types, but dev hits Node.js shims or getPlatformProxy()
  • OpenNext (Tier 3): Bindings accessible but dev runs Node.js entirely

Are you migrating from Next.js?

Two paths:

  1. Keep Next.js: Use OpenNext adapter. Supports App Router, Pages Router, RSC, ISR, streaming, Server Actions. Main cost is no workerd dev parity.
  2. 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 deploy auto-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.”