Next.js vs Remix: Which React SSR Framework Should You Use?

vercel/next.js is the most widely used React server-side rendering framework. You scaffold it with npx create-next-app, drop files into an app/ directory, and each file becomes a route. Next.js renders React Server Components on the server by default, ships minimal client JavaScript, and supports streaming, server actions for mutations, and three rendering modes — static (SSG), server (SSR), and incremental (ISR) — chosen per route.

vercel/next.js gives you a lot for one dependency: built-in image optimization, file-based routing, layouts, middleware, and first-class TypeScript. It is backed by Vercel, so deployment is one command and the docs and community are the largest in this list. The downsides are real — the App Router and Server Components have a steep learning curve, Next.js couples most tightly to Vercel's hosting, and the framework moves fast enough that patterns churn between major versions.

Pick vercel/next.js when you want the safest, most-hireable default for a production React app and don't want to assemble routing, data loading, and bundling yourself. If you'd rather lean on native web forms and progressive enhancement, pick remix-run/remix instead; if your site is mostly static content, gatsbyjs/gatsby fits better.

remix-run/remix is a React framework built around web fundamentals. You define nested routes as files, and each route exports a loader for reads and an action for writes; Remix runs these on the server, renders HTML, and wires native <form> submissions to your actions so mutations work even before JavaScript loads. Data loads per nested route segment and streams to the browser.

remix-run/remix's strengths are three: progressive enhancement, its loader/action data model that keeps server and client in sync, and excellent built-in handling of forms, errors, and race conditions. The tradeoffs: Remix has a smaller plugin community than Next, its static-site story is weaker, and the project's direction has been folding back into React Router, which creates some uncertainty about long-term branding and APIs.

Choose remix-run/remix when you value resilient, standards-based apps — forms that work without JS, clean data mutations, and nested layouts. If you instead need the broadest ecosystem, the most hosting options, and React Server Components, pick vercel/next.js; if you're building a static content site, gatsbyjs/gatsby is the better tool.

fastify/fastify is a fast, low-overhead Node.js web framework — an HTTP server, not a React renderer. You define routes and handlers, and Fastify focuses on high request throughput, schema-based validation with JSON Schema, and a plugin system. It can serve a React app or run SSR if you bolt rendering on top, but Fastify itself knows nothing about React.

fastify/fastify's strengths are real: it's one of the fastest Node servers, has first-class JSON Schema validation and serialization, and a clean plugin and hook architecture. In this category, though, Fastify is a foundation, not a solution — it gives you no routing-to-component mapping, no hydration, and no data-loading conventions, so you'd build the entire SSR layer yourself on top of it.

Pick fastify/fastify when you need a fast Node API server, possibly as the backend behind a React app. For actually rendering React on the server, pick a real framework like vercel/next.js or remix-run/remix, which run on Node and handle rendering for you.

marko-js/marko is an HTML-based UI language and framework from eBay, not a React tool. You write components in Marko's .marko syntax — HTML with embedded logic — and Marko compiles them, streaming rendered HTML to the browser and shipping JavaScript only for the interactive parts (its partial-hydration model). Marko was built for fast, content-heavy commerce pages.

marko-js/marko's strengths are streaming and minimal client JavaScript: it pioneered partial and progressive hydration, renders extremely fast, and sends little JS for mostly-static pages. The drawbacks for this list: it's its own language, not React — Marko won't run React components, its ecosystem and hiring pool are small, and the newer Marko 6 rewrite means some churn in APIs and tooling.

Pick marko-js/marko for performance-critical, content-heavy sites — large e-commerce catalogs — where streaming HTML and tiny JS payloads matter most and you'll adopt its language. For React SSR, pick vercel/next.js or remix-run/remix instead.

TanStack/router is a client-first, fully type-safe router for React that has grown a server-capable, full-stack mode (TanStack Start). You define routes as a typed tree, and TanStack Router gives you end-to-end type inference on params, search params, and loaders — its typed search-param handling is its signature feature. The full-stack layer adds SSR, streaming, and server functions.

TanStack/router's strengths: it has the strongest TypeScript story in this list, treats URL search params as typed first-class state, and integrates cleanly with TanStack Query for caching. The tradeoffs: the full-stack and SSR side is newer and less battle-tested than Next or Remix, the type-heavy API has a learning curve, and documentation for the server features is still maturing relative to the established frameworks.

Pick TanStack/router when type safety and sophisticated, typed routing — especially search params — matter most, and you want a client-first app that can also render on the server. If you need a mature, proven SSR framework today, pick vercel/next.js or remix-run/remix instead.

trpc/trpc is an end-to-end typesafe API layer, not an SSR renderer. You define backend procedures (queries and mutations) on the server, and tRPC infers their input and output types so your React client calls them with full autocomplete and no codegen or schema files. It commonly runs inside a Next app, where the same TypeScript types flow from server to client.

trpc/trpc's strengths are tight feedback loops: it gives you compile-time-safe API calls without REST or GraphQL boilerplate, integrates with React Query for caching, and catches contract breaks at build time. Its limits in this category: tRPC renders nothing on its own, it requires TypeScript on both ends, and it assumes a monorepo where client and server share types — it's a data layer that pairs with a framework, never a replacement for one.

Pick trpc/trpc when you control both client and server in TypeScript and want typed APIs without codegen — most often alongside vercel/next.js. For the actual server-side rendering, choose Next or remix-run/remix, and add tRPC for the data layer if you want it.

sveltejs/kit (SvelteKit) is the official application framework for Svelte, not React. SvelteKit provides file-based routing, SSR, static generation, form actions, and load functions for data, built on Vite. You write Svelte components — which compile to small, imperative JavaScript with no virtual DOM — and SvelteKit renders them on the server and hydrates on the client.

sveltejs/kit's strengths: it produces very small bundles thanks to Svelte's compiler, has clean form actions and load functions, and offers adapters that deploy the same app to many hosts. The category caveat is the same as the other non-React entries — SvelteKit renders Svelte, not React, so it can't run your React components, and choosing it means adopting Svelte's component model wholesale.

Pick sveltejs/kit when you want Svelte's compiled-away runtime and small output and are happy writing Svelte. If you need React SSR specifically, SvelteKit isn't a fit — pick vercel/next.js or remix-run/remix instead.

nuxt/nuxt is the full-stack framework for Vue, not React. Nuxt gives Vue developers file-based routing, server-side rendering, static generation, auto-imported components, and a server engine (Nitro) for API routes. You write Vue single-file components and Nuxt handles SSR, hydration, and deployment targets — it's essentially the Vue equivalent of Next.

nuxt/nuxt's strengths are a polished developer experience: auto-imports, a large module ecosystem, the flexible Nitro server that deploys to many platforms, and mature SSR and SSG. But for a React team Nuxt is a non-starter — it renders Vue components, not React, so adopting it means switching frameworks entirely; its relevance to a React SSR decision is only as a reference point for what good DX looks like.

Pick nuxt/nuxt if your team writes Vue and wants a Next-class framework for it. For React server-side rendering — the actual subject here — Nuxt doesn't apply; choose vercel/next.js or remix-run/remix instead.

preactjs/preact is a 3kB alternative to React with the same modern component and hooks API. Preact isn't itself a server-rendering framework — it's the rendering library, and it ships preact-render-to-string for SSR. You write components as in React, alias react to preact/compat, and get a much smaller runtime that renders to HTML on the server and hydrates on the client.

preactjs/preact's strengths are size and speed: it's tiny, fast to load, and largely drop-in compatible with the React API and ecosystem. The tradeoffs: some React libraries assume internals Preact doesn't replicate, compat aliasing occasionally breaks edge cases, and Preact alone gives you no routing, data loading, or build setup — you need a framework like preactjs/wmr or natemoo-re/microsite around it to build a real SSR site.

Pick preactjs/preact when bundle size is critical — widgets, embeds, performance-obsessed sites — and you want React's API at a fraction of the weight. For a full React SSR app with routing and data loading handled, pick vercel/next.js or remix-run/remix instead.

gatsbyjs/gatsby is a React framework that pre-renders your site to static HTML and assets at build time. You write React pages and pull content through a central GraphQL data layer that aggregates Markdown, CMS APIs, and files into one queryable graph. Gatsby builds every page ahead of time, then hydrates into a React app for client-side navigation.

gatsbyjs/gatsby's strengths are fast static output, a rich plugin library for sources and image processing, and that unified GraphQL layer that makes content from many sources feel like one dataset. The costs: Gatsby has slow builds on large sites, the GraphQL indirection is overkill for simple projects, and its momentum has faded since the company was acquired, so newer SSR features lag behind Next and Remix.

Pick gatsbyjs/gatsby for content-heavy static sites — blogs, docs, marketing — where build-time rendering and the image pipeline pay off. If you need server-rendered, frequently-changing data or per-request logic, pick vercel/next.js instead, which handles SSR and incremental regeneration far more comfortably.

solidjs/solid-start is the full-stack framework for Solid, not React. SolidStart pairs SolidJS's fine-grained reactivity with file-based routing, server-side rendering, streaming, and server functions, built on Vite. You write Solid components — which compile to direct DOM updates without a virtual DOM — and SolidStart handles SSR, routing, and data loading around them.

solidjs/solid-start's strengths: it delivers excellent runtime performance from Solid's compiled fine-grained reactivity, small bundles, and a modern Vite-based dev experience with streaming SSR. The catch for this list is that it's Solid, not React — solid-start won't run your React components, its ecosystem is smaller, and the framework reached 1.0 relatively recently, so it's less battle-tested than Next.

Pick solidjs/solid-start when you want top-tier performance and are willing to write Solid instead of React. If you need React specifically, it's out — choose vercel/next.js or remix-run/remix, and consider SolidStart only if you're open to switching component models.

google/js-green-licenses is not a React server-side rendering tool at all — it's a command-line license checker for JavaScript projects. You run it against a package.json and it walks your dependency tree, flagging packages whose licenses aren't on an allowed 'green' list. It exists to catch GPL or otherwise restricted licenses before they ship.

As a license tool, google/js-green-licenses is useful in CI: it's simple, configurable with an allow/deny list, and made by Google. But within this category it has zero SSR functionality — js-green-licenses renders nothing, serves nothing, and competes with none of the frameworks here. Its presence in a React SSR list is a curation mismatch, and it should not factor into any rendering decision a team makes.

Pick google/js-green-licenses only when you need automated license compliance checks in a Node project's pipeline. For anything involving rendering React on the server, ignore it entirely and choose vercel/next.js, remix-run/remix, or gatsbyjs/gatsby.

t3-oss/create-t3-app is not a framework but a scaffolding CLI that wires together a proven full-stack stack. You run npm create t3-app, answer a few prompts, and it generates a vercel/next.js project pre-configured with TypeScript, Tailwind, tRPC, Prisma, and NextAuth — the 'T3 stack.' create-t3-app's job is to remove the setup friction of stitching those tools together correctly.

t3-oss/create-t3-app's strengths: it gives you a typesafe, batteries-included Next app in minutes, with sensible defaults and modular prompts so you only include what you need. The drawbacks: it's a starting point, not a runtime — create-t3-app does nothing after scaffolding, the generated stack is opinionated toward Next plus tRPC plus Prisma, and you inherit the learning curve of all those tools at once.

Pick t3-oss/create-t3-app when you want the popular typesafe Next stack bootstrapped correctly without assembling it by hand. The actual SSR comes from vercel/next.js underneath; if you don't want tRPC and Prisma baked in, scaffold Next directly or pick remix-run/remix.

redwoodjs/redwood is a full-stack, opinionated framework for React startups. You scaffold with yarn create redwood-app and get a monorepo split into a React front end (Redwood's web side) and a GraphQL API side backed by Prisma. Redwood generates cells — declarative components that handle loading, empty, and error states around a GraphQL query — and wires routing, auth, and the database layer together.

redwoodjs/redwood's strengths are integration and code generation: Redwood gives you GraphQL, Prisma, auth, and testing scaffolds in one coherent setup, which is fast for greenfield apps. The downsides: it's heavily opinionated and the GraphQL-everywhere model is overkill for simple sites, its SSR and streaming story arrived later than Next's, and the all-in-one structure is hard to escape once you're deep in it.

Pick redwoodjs/redwood when a startup wants a batteries-included full-stack React app with a database and GraphQL API from day one. If you want lighter-weight SSR or to choose your own backend, pick vercel/next.js, or remix-run/remix for a server-first model without mandatory GraphQL.

blitz-js/blitz is a full-stack toolkit layered on top of vercel/next.js. Blitz keeps Next's rendering and adds a 'zero-API' data layer — you write server functions as queries and mutations and call them directly from React components as if they were local, and Blitz handles the RPC, validation, and types in between. It also bundles auth and a Prisma-based database setup.

blitz-js/blitz's strengths are developer speed: Blitz removes the boilerplate of building REST or GraphQL endpoints, ships authentication and session handling, and inherits Next's rendering. The drawbacks: it depends on Next's direction, the project went through a rocky pivot from a framework to a toolkit that cost it momentum, and the magic RPC layer can obscure what's running on the server versus the client.

Choose blitz-js/blitz when you're already committed to Next and want its direct-call data layer plus built-in auth to move fast. If you prefer a typed API contract you control, pair vercel/next.js with trpc/trpc instead; if you want a server-first model, pick remix-run/remix.

preactjs/wmr is a tiny all-in-one development tool for Preact apps with no configuration. WMR bundles a dev server, build, prerendering, and routing into a single dependency — you write Preact components and WMR serves them during development and prerenders pages to static HTML for production. It supports SSR and prerendering of routes without a config file.

preactjs/wmr's strengths are simplicity and weight: zero config, a single small dependency, native ES modules in dev for fast startup, and built-in prerendering. The downsides: WMR is a Preact tool with a small community, it's far less actively developed than current Vite-based stacks, and its SSR and prerender features are modest compared with full frameworks like Next or Remix.

Pick preactjs/wmr for small Preact projects where you want zero-config bundling and prerendering in one tiny tool. For a full-featured React SSR app — real data loading and server rendering at scale — pick vercel/next.js or remix-run/remix.

natemoo-re/microsite is a performance-obsessed static site generator powered by Preact. Microsite renders your pages to static HTML at build time and ships almost no JavaScript by default, using partial hydration so only components you explicitly mark as interactive (withHydrate) send client code. You write Preact components and Microsite outputs lean static pages.

natemoo-re/microsite's strengths are minimal JavaScript and fast static output: it defaults to zero client JS, hydrates only what you opt in, and produces very light pages. The drawbacks are significant for most teams — Microsite is a small, low-activity project, it's static-only with no real server rendering or dynamic per-request data, and it's tied to Preact rather than React proper.

Pick natemoo-re/microsite for tiny, static, performance-critical sites where shipping near-zero JavaScript is the goal. For dynamic server rendering, real data loading, or a large React app, pick vercel/next.js or remix-run/remix instead.