Next.js Comparison

Vike differs from Next.js in three fundamental ways:

Vike is agnostic to Deployment / hosting.
Vike is full-fledged yet Minimal and self-contained (no deps).
Vike is UI Framework agnostic.

Beyond these structural differences, Vike introduces features such as blazing fast HMR (powered by Vite), optional SSR, Domain-driven File Structure, state-of-the-art Code Splitting (powered by Vite/Rollup), Automatic Deployment Synchronization, Build your own framework, etc.

Turbopack replicates some of Vite's techniques, but it's still in its infancy and it will take a while until Turbopack is production-ready. With Vite, you can use lightning fast DX today.

Finally, Vike is a community project: instead of leaning on a framework with business interests that are fundamentally at odds with yours, use a community-driven project that is sponsored by, made for, and made by the community.

Detailed comparison table

From @patryk-smc and @redbar0n:

	Vike	Next.js
Bundler	Vite (dev: esbuild+ESM, prod: Rollup)	Webpack
UI Framework	Any (React, Preact, Solid, etc.)	React only
Code-splitting and bundling	Yes	Yes
HMR	Yes, fast	Yes, slow
Optional SSR	Yes	Limited (app[1], pages[2][3], components[4][5])
SSR
Control	Full control	Limited / Black box
Renderers	Yes, create as many you need	Just one (`_app.ts` file)
RSC (React Server Components)	Yes, partially	Yes, experimental
Routing
Filesystem Routing	Yes	Yes
Domain-driven Filesystem Routing	Yes	No
Client Routing	Yes	Yes, but limited in SPA-only mode ***
Server Routing	Yes	No
Base URL	Yes	Limited
Pre-rendering (SSG)
Pre-rendering (SSG)	Yes, for pages	Yes, for pages, or components (Partial Pre-rendering using RSC)
Incremental Static Regeneration (ISR)	No*, use vite-plugin-vercel	Yes, in the Node.js runtime, on Vercel
SPA-only mode (popular for PWAs) ***	Yes	Limited: no dynamic routing in App Router
Integrations
HTTP server	No*, bring your own	Baked-in, custom server partially supported with caveats[1][2]
Apollo Client with SSR	Fully supported	Partially supported
Relay with SSR	Fully supported	Partially supported
Extras
Head component	No*, use a tool like react-helmet.	Yes, next/head
Image component	No*, use an image optimizer tool.	Yes, next/image
API routes	No*, use your server or an RPC tool.	Yes
Internationalization (i18n)	Yes	Limited
Deployment synchronization	Yes	No
Build your own framework	Yes	No
Deployment options
Vercel	Yes, minimal config	Yes, zero config
Cloudflare Workers	Yes, minimal config	Yes, but limited
Node server (Docker, Heroku, Digital Ocean etc.)	Yes, minimal config	Yes, but limited
Caching (see own section above)	No, if needed, use industry-standard caching*.	App Router caching, opt-out

(*) Vike doesn't ship those extras by design.

(**) Industry-standard ways of caching is to use the HTTP Cache-Control header to cache in the client's browser and potentially also on a shared/public CDN cache in front of your server side. Additionally, if you ever need even more caching than that, it's possible to have an in-memory cache on your server-side using e.g. Redis or Memcached.

(***) SPA-only mode means you make a static export of your app, into HTML, CSS and JS files, and serve them from a CDN, which means you don't need any server compute on requests (as opposed to SSR).

User feedback

From @Axxxx0n:

Blazing fast development speed powered by Vite (on-demand transpiling, native ESM).
Next.js has to have many examples and a whole plethora of libraries are existing just to integrate some library with Next.js because it's not trivial (for example next-i18next). With Vike, you just read the documentation of the library you want to integrate and you're good to go.
When new React features arrive you can start to use it right away and don't have to wait for the Next.js team to integrate it. (Streaming API, server components, suspense on server, progressive rendering, etc.)
Next.js can't read files in /public directory after it was built, i.e. user uploaded images.
With getServerSideProps(), Next.js blocks client-side rendering.
You cannot bypass data fetching on client-side navigation (Next.js - #23921) while with Vike you're flexible and can choose what you want.
Next.js is really pushing the Vercel platform and is starting to show in recent feature updates. Features that align with this are getting priority while important fixes are delayed.
Next.js is leaning on serverless and complicates usage when you don't want it.

Deployment / hosting

Next.js - optimised for Vercel

Next.js is made by Vercel, a hosting provider. It is therefore naturally optimised to run in their environment and infrastructure. But Vercel is known to become very expensive at scale. What's worse is that Vercel's pricing is misleading (the pay-per-developer make it seem cheap but you usually pay for very expensive fees for exceeding limits), opaque (e.g. you must have an enterprise plan if you have >10 team members which is hidden in the fine print), locks you in with extremely expensive egress fees, hard to understand and nearly impossible to predict. Such pricing is a no-go for large enterprises.

You can self-host Next.js as a Node.js server, for example placed in a Docker container. But it won't work precisely the same way as on Vercel. Furthermore, self-hosting Next.js as a Serverless or Edge application (i.e. replacing Vercel) is worse.

An illustration of the problem: with Next.js server actions you no longer handwrite API endpoints - which means you don't have the ability to explicitly control versioning. So requests from old clients can fail. Vercel solved this with their deployment infrastructure, instead of in Next.js itself. So if you use Next.js but not Vercel then you'll have to deal with this major problem yourself.

These kinds of difficulties led the open source community to develop Open-Next.js, a project to make Serverless deployment of Next.js on generic Functions-as-a-Service (FaaS) platforms easier (specifically on AWS Lambda). It allows easier integration with AWS and reduces Next.js's ties to Vercel. But that is a moving target with things breaking frequently, according to a person working closely with the matter.

Edge deployment with Next.js is another story. Cloudflare, the most prominent edge hosting provider, uses its own runtime instead of Node.js. Meaning that some Next.js apps built to run on Node.js won't immediately work on the Edge. So Next.js has an Edge Runtime toolkit/mode that uses only a subset of the Node.js API, but it has a lot of issues.

Vike - hosting agnostic

With Vike, you keep full control over your server and you can use any deployment strategy.

Vike is server and deployment agnostic, which means you can use any hosting provider and any server/serverless setup of choice. Vike is built with Serverless and Edge compatibility from the start.

From a server perspective, Vike is just a middleware that doesn't depend on Node.js and that can run anywhere where JavaScript runs such as AWS, Vercel, Cloudflare, Deno Deploy, or even in the browser.

You can develop apps with a server that doesn't depend on Node.js and deploy it anywhere.

You can also pre-render your app to remove the need for a production server: your app consists only of static assets (HTML, JS, CSS, images, ...) that can be deployed to any static host such as GitHub Pages.

You do need Node.js for local development, as the development runtime of Vite (the dev- and build-toolkit used by Vike) depends on Node.js. But Vite's runtime isn't needed in production. Consequently, since Vike's runtime doesn't depend on Node.js, there are no dependencies on Node.js in production.

To integrate Vike, you simply add Vike's middleware to your server (Express.js, Fastify, Edge Worker, Serverless Function, etc.).

With Vike, you have full control over your server and over your deployment strategy, two critical aspects of your business.

Minimal and self-contained (no deps)

All dependencies are either shared with Vite (e.g. fast-glob) or fully owned (e.g. we own @brillout/json-serializer). Adding Vike to your Vite app doesn't add any frivolous dependency.

We believe Vike hits the sweet spot of being a full-fledged frontend tool while avoiding unnecessary bells and whistles.

Caching

Next.js - caches by default, must opt-out

Next.js aggressively uses caching, for performance and cost-saving reasons. Less server load means your app uses less compute resources, which saves you money on Vercel's paid plans, but saves Vercel money on their free tier (which most developers will be on; Vercel's long-tail).

Next.js leans towards making as many routes as possible statically rendered (SSG over SSR wherever possible). Caching is enabled by default (both on the server and the client), and you have to explicitly opt-out to disable it (using more or less hacky solutions) each time you don't want it.

But people are finding the aggressive caching to be a nightmare, and hard to disable. Caching can give a wrong/stale view of your app, and cost precious development time hunting for the cause.

As the saying goes, "There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton

Vike - opt-in caching

Vike does not cache, by design, so by default your app will behave as you expect. If you do want caching, you can opt into it by using one of the many industry-standard caching tools.

Server vs. client workloads

Next.js - server-first oriented

Next.js - made by Vercel, a hosting provider - is server-focused. It now defaults to interpreting all React components in the React render tree as React Server Components (RSC), and if you don't want that, you have to opt-out.

With RSCs, you have to inject the bundler directive "use client" (aka. start client bundling) into your React component tree at the start of every branch with components that you want to turn into Client Components.

The default server orientation makes sense for websites that consist of large static sections with no client interactivity. Using RSCs reduce the size of client-side bundles (and hydration), due to the JS code in RSC's only running on the server (e.g. useful for a static site using a heavy markdown library). But RSC's carry serialization and parsing overhead, has special rules (no state, context, or effects), and conceptual overhead that many developers struggle with.

In addition, with Next.js new App Router, there's been a long standing open issue that you can't render dynamic routes in the app when it is exported to static assets. This is the so called SPA-only mode (render everything only on the client; often used for PWAs), which means you could serving your app from a CDN, and thus obviating the need any server compute.

In all, the fact that Next.js leans more on the server (and RSC's and caching by default) may not be what you want, especially if you are building a webapp which you expect will become more and more dynamic and interactive anyway.

Vike - granular work-split between server and client

If your product either should be:

leaning more towards being an app than a site/page.
having a lot of dynamically generated and/or frequently updating content (coming from a DB), where caching doesn't give a lot of gains.
having a single unified model for data loading that may include polling and live UI updates.
local/offline-first, and/or a PWA.
cross-platform (reusing code between web and native), since native platforms are typically client-centered (and it isn't prioritized or very clear how React Server Components would work on React Native).
using less server resources (scalability, cost-wise), in favor of requiring slightly more processing power on the client. Like using a SPA-only mode (static export, to serve from CDN, with no server compute needed), which is often a favored approach for PWAs.

then the server-first orientation of Next.js and Vercel isn't helpful and can be a hindrance.

With Vike, you can choose setups that fit the aforementioned use cases. You can partially or completely opt out of SSR (turn on/off for whole app, for some pages, or for some components). You can also use SSR for the first page and then, from there on, use client-only navigation while fetching data directly from the data source (without involving your SSR server).

Vike has first-class support for leaning towards the client-side, as well as first-class support for SSR use cases. Vike is made by the community and has no incentive to favor any side of the work-split between the client and the server.

UI Framework agnostic

Next.js is deeply tied to React. So if you want to move to another UI framework later, like for instance SolidJS, then it means a laborious refactor away from NextJS. But with Vike, you keep your options open, and can swap out your UI framework rather easily with various UI extensions for Vike.

Vike is completely agnostic to React and its source code has zero dependency on React. You can actually use Vike with any other UI Framework (Vue, Preact, Solid, etc.).

With Vike, you implement and fully control the React integration, which has many benefits. For example, you can use Relay in the same way that Facebook does (with a render-as-you-fetch stream) which isn't possible with Next.js.

With Vike, you can integrate React yourself. This means you need to write a little bit more boilerplate, but in exchange you get a lot more flexibility. You can even use vike-react to do it for you, and later when you need more control you can eject. If you want to switch UI framework to Solid, then you can swap vike-react with vike-solid.

Because you can control the React integration, you also have full control over the frontend integration of your favorite tools (data fetching, state management, authentication, etc.).

For example, you can use Relay and Apollo in ways that aren't possible with Next.js.

Relay is a state-of-the-art GraphQL client developed and used at scale by Facebook (which invented GraphQL). The YouTube video "Re-introducing Relay" explains in detail the benefits of Relay.

Many users and sponsors leverage Vike's flexibility to integrate Relay with SSR Streaming.

Vike includes everything you'd expect from a frontend framework: Client-side Routing, HMR, Filesystem Routing, Pre-rendering (SSG), Data Fetching, Code Splitting, Layouts, i18n, etc.

Manual integrations

As depicted above, Vike's philosophy is that you integrate tools manually instead of being locked into decisions made by your framework. Use any tool you want, however you want.

All-in-all, Vike is less easy, but simpler. For large scale projects, simplicity is fundamentally more important than being "easy".

Last but not least, manual integration is fun and insightful. (Whereas fighting a framework is pesky.)

React Server Components

React 18 introduced novel techniques that unlock many capabilities.

Vike, and in particular vike-react, extensively leverages React's 18 new techniques. (Streaming, Progressive Rendering, independent and collocated data fetching, RPC, etc.)

Vike provides you with extensive control for integrating tools as you see fit, such as control over React's SSR stream. At the same time Vike extensions provide built-in integrations for a quick start. We call this dual approach optional control.

One aspect vike-react doesn't support yet are components that are loaded only on the server-side. While we are researching a DX for such components, we believe this new paradigm is too early for being used in production. See Integration > React > React Server Components.

Build your own framework

Vike is designed from the ground up to enable users to build frameworks on top of Vike.

You can build your own framework with only hundreds of lines of code.

While there are many uses cases for building your own framework, the most prominent one is building company internal frameworks.

We foster the proliferation of React frameworks, highly-tailored to specific use cases.