Vike differs from Next.js in three fundamental ways:
- Vike is UI Framework agnostic.
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.
- Vike is server and deployment agnostic.
With Vike, you keep full control over your server and you can use any deployment strategy.
- Vike is full-fledged yet minimal.
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.
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 from the community.
UI Framework agnostic
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.
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.
Next.js is made by Vercel, a hosting provider. It is therefore naturally optimised to run in their environment and infrastructure. But Vercel
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 is server and deployment agnostic (use any server and any hosting provider), and built with Serverless and Edge compatibility from the start.
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.
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.
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.
- 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.
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.
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 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.
Next.js - made by Vercel, a hosting provider - is server-focused. It now defaults to interpreting all React components as Server Components, so you have to mark React components with "use client" to opt-out of always hitting the server. It makes sense for many types of apps as it reduces the size of client-side bundles (the client doesn't need to download JS libraries that now by default run on the server, e.g. markdown). But the fact that Next.js leans more on the server may not be what you want.
If your product either:
- leans more towards being an app than a site/page
- has a lot of dynamically generated and/or frequently updating content (coming from a DB), where caching doesn't give a lot of gains
- is a PWA and/or local/offline-first
- is a cross-platform app (reusing code between web and native), since native platforms are typically client-centered (and Server Components don't work on React Native)
- should use less server resources (scalability, cost-wise), in favor of requiring slightly more processing power on the client
then the server-first mentality 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.
Detailed comparison table
From @patryk-smc and @redbar0n:
|Vite (dev: esbuild+ESM, prod: Rollup)
|Any (React, Preact, Solid, etc.)
|Code-splitting and bundling
|Limited / Black box
|Yes, create as many you need
|Just one (
|RSC (React Server Components)
|Domain-driven Filesystem Routing
|No*, bring your own
|Baked-in, custom server partially supported with caveats
|Apollo Client with SSR
|Relay with SSR
|No*, use a tool like react-helmet.
|No*, use an image optimizer tool.
|No*, use your server or an RPC tool.
|Build your own framework
|Yes, minimal config
|Yes, zero config
|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.