Next.js Is Dying. Meet Vike.

The Silent Drag on Your React App

React developers keep describing the same uncanny sensation: their Next.js app feels slow even before it gets big. You click a link on localhost and wait 1–2 seconds for the dev server to respond, hot module replacement stutters, and every change feels like pushing code through molasses rather than iterating in real time.

That drag isn’t just about perception; it comes from the framework’s weight and ambition. Next.js tries to be your router, bundler, server runtime, data layer, and deployment story all at once, and every “convenience” layer sits between you and the browser, adding overhead to both build times and feedback loops.

The all-in-one design also bakes in a very specific way of building React apps. File-system routing, API routes, server components, app router conventions, and Vercel-centric deployment defaults create a tight bundle of assumptions that work brilliantly for a blog or landing page, but start to pinch when you need unconventional data flows or custom infra.

Once you buy into those opinions, backing out gets expensive. Want to swap out routing, experiment with a different rendering strategy, or gradually introduce another UI stack? With Next.js, you often face full rewrites, brittle workarounds, or a maze of configuration that still fights the framework’s defaults.

Developers are discovering this as a time-bomb trade-off. You move fast for the MVP, but as the app grows into a multi-tenant dashboard or a complex SaaS, the same abstractions that felt magical become friction: slower builds, larger bundles, and patterns that resist refactoring.

That friction shows up in the shipped code as well. Typical Next.js client bundles for non-trivial pages easily climb into the 70–100 kB range before you add serious UI libraries, while lighter setups routinely stay in the 10–15 kB band, which directly affects load times, Time to Interactive, and lighthouse scores.

Developer experience takes a hit alongside performance. Long cold starts on dev, opaque errors deep in the framework stack, and churn from major feature shifts like React Server Components all compound into a sense that the framework, not your product, dominates your day.

That’s why a newer generation of tools, including Vike on top of Vite, is explicitly targeting this heaviness—promising smaller bundles, faster feedback, and less lock-in without forcing you to abandon the React ecosystem.

Meet Vike: The 'Boring' Framework Winning Developers

Meet Vike, a modular meta-framework riding on top of Vite and explicitly gunning for the space Next.js carved out. Instead of a monolith that dictates routing, data fetching, and deployment, Vike focuses on one job: wiring SSR, SSG, and routing onto Vite’s blazing-fast dev server and bundler.

Born in 2021 as `vite-plugin-ssr`, Vike quietly evolved in the shadows while React developers argued about app routers and server components. A 2023 rebrand gave it a cleaner identity, and it has since climbed past 5,000 GitHub stars, signaling that this is no longer a weekend experiment but a framework with real gravitational pull.

Vike’s core philosophy feels almost reactionary in 2025: be unopinionated, stay MIT-licensed, and avoid hype-driven rewrites. The maintainers pitch it as “boring in a good way” — a tool that changes slowly, favors explicit configuration, and lets you bring your own stack for data, auth, and state instead of hard-wiring you into one blessed path.

Where Next.js leans hard on enforced conventions — `app/` vs `pages/`, file-based routes, server actions, React Server Components — Vike strips things down to primitives. You define routes, page configs, and rendering modes yourself, then opt into features like SSR, SSG, or client-only rendering on a per-page basis with simple booleans and config files.

That minimal, opt-in model extends to the UI layer. Vike doesn’t care if you use React, Vue, or Solid; the same project can mix them as “islands” on a single page without adapters or wrappers. You get low-level hooks and building blocks, not a framework that insists every component speak React Server Components or live in a prescribed directory tree.

Developers frustrated with Next.js’s frequent breaking changes and lockstep alignment with one hosting provider see Vike’s restraint as a feature, not a bug. No built-in image optimizer, no magic data layer, no proprietary API routes — just Vite, routing, and SSR primitives that stay out of your way while you assemble the rest of the stack yourself.

React, Vue, and Solid on the Same Page? Seriously.

React purists might want to look away, because Vike’s most subversive trick is that it stops caring which UI framework you use. Its routing, data loading, and rendering pipeline sit below the component layer, so the UI becomes a set of “islands” that can come from React, Vue, Solid, or anything else Vite can compile.

In the Better Stack demo, the About page runs as a standard React route, but the skills section in the middle of that page is a Vue component. No iframe, no micro-frontend shell, no custom adapter layer—just a Vue island mounted directly into a React page with no wrappers, no hacks.

That island model sounds academic until you think about micro-frontends. Vike lets teams carve an app into independently implemented slices, so one team can ship a Vue dashboard, another can maintain a legacy React checkout, and a third can experiment with Solid for a high-interaction widget, all inside one URL space.

Multi-tenant platforms benefit even more. A SaaS that white-labels dashboards for dozens of customers can host: - React-based admin tools - Vue-heavy analytics for a specific client - Solid-driven real-time widgets

All under one Vike app, without spinning up separate deployments or forcing every tenant onto the same stack.

Gradual migrations finally look sane here. Instead of a brutal big-bang rewrite, a team can replace a Next.js React page piece by piece: reimplement a single section as a Vue or Solid island, validate it in production, then expand the blast radius. Vike’s low-level hooks keep SSR, hydration, and routing consistent while the UI layer evolves.

Next.js simply does not make this easy. Its entire mental model, from file-system routing to data fetching and React Server Components, assumes React everywhere, all the time. Mixing Vue or Solid into a Next.js tree usually means brittle webpack hacks, separate builds, or full-blown micro-frontends with all the operational overhead that implies.

Vike, by contrast, leans on Vite’s ecosystem and treats frameworks as plugins rather than a religion. The project’s GitHub page, [vikejs/vike: [Next.js/Nuxt alternative] The composable ... - GitHub](https://github.com/vikejs/vike), explicitly advertises framework-agnostic islands and “unprecedented flexibility” as first-class goals.

For teams staring down a multi-year migration, a messy acquisition, or a portfolio of mismatched frontends, that flexibility is not a parlor trick. It is a way to keep shipping while your tech stack catches up to reality.

Shrink Your Bundle From 100kB to 15kB

Bundle size tells the story. In the Better Stack demo, Vike pages routinely ship client bundles in the 10–15 kB range, while comparable Next.js pages bloat to 70–100 kB+ before you add real app code. That 5–10x difference is not a rounding error; it rewires how fast your UI shows up and responds.

Vike pulls this off by riding directly on Vite instead of layering its own build system on top. Vite’s native ES modules, pre-bundling, and dev server mean hot module replacement feels almost instantaneous, not “wait two seconds and hope.” You see edits reflected in a blink, even as your project grows beyond toy status.

Next.js, by contrast, drags a larger runtime, more abstractions, and a lot of default client JavaScript into every route. You pay for routing, data hooks, and React Server Components wiring whether you use them or not. That baseline tax is why a “hello world” Next app already weighs tens of kilobytes in the browser.

Smaller bundles mean less JavaScript to download, parse, and execute, which directly cuts Time to First Byte (TTFB) and Time to Interactive. A 15 kB bundle often arrives in a single network round trip, especially on HTTP/2, and parses in milliseconds on mid-range phones. A 100 kB+ bundle has to fight bandwidth, latency, and slower CPUs before users can tap anything.

Vike’s design keeps the browser payload focused on your UI, not framework machinery. You ship only the islands and components that actually run on the client, instead of a monolithic app shell. No automatic client-side router if you don’t need one, no hydration logic for pages that render fine as static HTML.

That philosophy also makes performance more predictable. When you add a new feature, you can see exactly which modules hit the client bundle and by how much, thanks to Vite’s transparent build output. Performance tuning becomes about trimming real dependencies, not spelunking through framework internals you never asked for.

Your App, Your Rules: Ditching Black Box Abstractions

Next.js asks you to buy into its worldview. You get conventions like `getServerSideProps` and `getStaticProps`, automatic routing, and React Server Components wired in, but you also inherit a lot of invisible behavior: when data loads, how it caches, where code runs. Once your app stops looking like a blog, that “magic” becomes something you debug instead of benefit from.

Vike goes the other way and hands you the wiring. Rendering mode becomes an explicit config flag on each page (`ssr: true` or `false`), so you decide which routes pre-render, which hydrate, and which stay server-only. No hidden waterfalls, no framework guessing your intent from a filename.

Data fetching in Vike looks more like regular TypeScript than a framework ritual. Instead of special lifecycle functions, you use low-level hooks and a pattern called Telefunc to define server functions in `.ts` files and call them directly from the client. Vike handles serialization and routing under the hood but leaves control of when and how you fetch entirely to you.

Telefunc essentially replaces API routes for most use cases. You write something like `addEntry()` in a Telefunc file, import a generated client on the frontend, and call `await addEntry(...)` with full end-to-end typing. No `pages/api`, no REST boilerplate, no extra GraphQL layer unless you want one.

Because Telefunc just exposes functions, it plays nicely with existing tooling. You can wrap inputs in Zod schemas for runtime validation, then infer TypeScript types from those schemas for free. That gives you a single source of truth for data contracts instead of juggling DTOs, API handlers, and client types.

Vike also stays out of your caching strategy. Want to pair Telefunc with TanStack Query? You drop your Telefunc calls inside `useQuery` or `useMutation`, configure stale times and retries, and you have a fully custom data layer that still feels like idiomatic React. No fighting a framework-level cache that insists on revalidating or refetching at odd times.

Experienced teams tend to appreciate that kind of explicitness. If you already know how you want to do auth, error handling, and data normalization, Next.js’s batteries-included stack can feel like guardrails welded to the frame. Vike’s approach means more decisions up front, but you own each one.

That ownership matters when your app outlives the current meta. With Vike, your architecture is just TypeScript, Vite, and libraries you chose, not a black box that might pivot its data model again next year. For teams burned by breaking changes and hidden behavior, “your app, your rules” is not a slogan; it is risk management.

Photon: Vike's Secret Weapon for Edge Deployment

Photon is the part of Vike that quietly answers the hardest question in modern web frameworks: where does this thing actually run? Billed as deployment tooling rather than yet another runtime, Photon packages your Vike app so it drops cleanly onto edge platforms like Cloudflare Workers and Vercel without a bespoke DevOps ritual for each target.

Instead of shipping a chunky Node server, Photon compiles your routes into tiny, edge-friendly functions. That lines up with Vike’s whole “small bundles, small surface area” story: minimal JavaScript on the client, minimal overhead on the server, and no monolithic process idling in a region you did not pick.

The result is exactly what edge vendors have been promising for years: no cold starts and very low TTFB. Workers spin up close to users, Vike streams HTML fast, and you avoid the 300–800 ms penalty that comes with booting a traditional Node server, especially on low-traffic routes or multi-region setups.

Photon also tries to normalize the chaos of edge platforms. Instead of learning Cloudflare’s quirks, Vercel’s edge runtime rules, and every provider’s filesystem traps, you configure Vike once and let Photon emit the right artifacts and adapters per target.

That positions Vike squarely in the edge-first camp alongside Remix and SvelteKit, which already lean on distributed runtimes for speed. The difference is philosophical: Vike stays closer to Vite and classic SSR primitives, while Photon handles the last-mile translation to Workers-style environments.

Edge deployment is quickly becoming table stakes for React-era frameworks. Guides like Top 5 Next.js alternatives for React developers - LogRocket Blog increasingly treat “runs on the edge” as a checkbox, not a bonus, and Photon is Vike’s answer to that expectation.

For teams stuck between Next.js’s Vercel-first assumptions and DIY Vite SSR setups, Photon turns Vike into a credible, production-ready option that actually belongs on the global edge.

Why Vike Isn't for Everyone (Yet)

Vike’s biggest selling point—control—also becomes its sharpest edge. You do not get the “batteries-included” comfort that made Next.js the default React answer for startups and agencies. Vike hands you primitives and expects you to assemble a framework, not just a project.

Out of the box, you will not find the grab‑bag of conveniences Next.js developers take for granted. No built‑in image optimization pipeline, no first‑party auth solution, no opinionated API routes layer, and no official analytics, fonts, or middleware stacks. You wire up things like file uploads, rate limiting, and caching yourself, usually by picking third‑party libraries.

That modularity feels powerful only if you already know what pieces you want. For many teams, the missing ecosystem of presets hurts more than the raw performance wins help. You trade Next.js’s “drop in a plugin and go” experience for reading docs and stitching together tools like TanStack Query, Zod, and your own routing conventions.

Next.js also dwarfs Vike on community gravity. Next has thousands of tutorials, Stack Overflow answers, and production case studies; Vike has a handful of blog posts, a smaller Discord, and scattered GitHub examples. When you hit a weird SSR edge case or deployment quirk, you are less likely to paste an error into a search bar and find a copy‑paste fix.

That smaller ecosystem translates to fewer polished integrations. You will not see a marketplace of official adapters for every headless CMS, auth provider, and payment gateway. Instead, you are wiring in services like Auth0, Clerk, or Stripe manually, deciding how tokens flow through server functions and how to hydrate state on the client.

React‑first teams face another catch: React Server Components are not fully there yet. Vike can approximate the pattern with server functions and selective hydration, but you do not get the seamless RSC story that Next.js 13+ leans on. If you are already invested in RSC patterns, layouts, and streaming, Vike currently feels like a step sideways, not forward.

Bare-Bones Can Feel Bare-Knuckled

Bare-bones Vike feels empowering right up until you realize you now own everything. That freedom to pick your router, your data layer, your caching strategy, and your auth stack also means a higher initial setup cost and an ongoing maintenance bill that used to be Next.js’s problem, not yours.

Developers used to `create-next-app` get a rude awakening when a Vike project starts as little more than routing, SSR/SSG primitives, and some config files. You choose how to structure pages, where to put API calls, and how to handle cache invalidation, which slows down greenfield projects that just need to ship.

The video calls out the learning curve as “a bit of a joke” precisely because Vike refuses to hide complexity. You wire up data fetching and caching yourself with hooks, instead of dropping logic into `getServerSideProps` or `getStaticProps` and letting the framework orchestrate everything.

Documentation amplifies that pain once you leave the happy path. Basic SSR and routing feel clear enough, but advanced React setups, mixed-framework islands, and edge-specific patterns still have patchy docs, forcing devs to reverse-engineer examples or trawl GitHub issues.

That flexibility around data shows both sides of the coin. Want TanStack Query, custom fetch wrappers, or a homegrown RPC layer? Vike stays out of your way, but it also refuses to give you a blessed, batteries-included solution that a team can standardize on by default.

Every serious project ends up assembling its own stack for:

• Data fetching and caching
• Auth and sessions
• Image optimization and asset handling
• Error boundaries and observability

Ownership also means owning the sharp edges. The video mentions recurring hydration mismatches in React-heavy apps and TypeScript quirks that you never see in Next.js because Vercel’s framework has spent years sanding those down.

Teams migrating from Next.js’s polished rails to Vike’s open toolbox feel that friction most. You trade guardrails and integrated DX for raw control, and the first few weeks can feel less like a productivity boost and more like bare-knuckled framework engineering.

When to Bet on Vike (And When to Stick with Next.js)

Choosing between Vike and Next.js starts with a blunt question: are you optimizing for the next three months or the next three years? Short timelines and fuzzy requirements favor convention and batteries included. Long-lived systems with evolving constraints reward explicit control and composability.

Vike shines when architecture matters more than scaffolding speed. Teams planning multi-year platforms, multi-tenant SaaS, or micro-frontend setups gain from its framework-agnostic islands, tiny 10–15 kB bundles, and per-page SSR/SSG toggles. You trade instant ergonomics for a system that bends instead of breaking when requirements shift.

Micro-frontends and gradual rewrites are where Vike feels unfair. Need to run React for your dashboard, Vue for a legacy admin, and Solid for a new marketing experiment on the same domain or even the same page? Vike’s low-level hooks and routing layer let you stitch that together without the “one framework to rule them all” constraints that make similar moves in Next.js painful.

Performance-obsessed teams also have a strong case for Vike. If your budgets demand sub-20 kB initial payloads, edge rendering via Photon on Cloudflare Workers or Vercel, and minimal hydration overhead, Vike’s lean core and Vite-powered HMR give you more headroom than a typical 70–100 kB Next.js bundle. You own the trade-offs instead of inheriting them.

Next.js still wins when you need to ship yesterday. For rapid MVPs, content-heavy marketing sites, and dashboards that lean on Markdown, CMS integrations, and image optimization, its built-ins reduce decision fatigue. You get file-based routing, API routes, image handling, and React Server Components without assembling a stack from scratch.

Teams heavily invested in the Vercel ecosystem should think twice before jumping. If your workflows already depend on Vercel previews, analytics, edge functions, and the broader Next.js plugin ecosystem, staying put keeps your tooling and hiring story simple. Swapping to Vike only to rebuild what Next.js gives you out of the box makes little sense.

Ultimately the call hinges on three variables: team expertise, project horizon, and appetite for ownership. Senior-heavy teams building long-lived, performance-critical systems can justify Vike’s upfront friction. Smaller teams, content sites, and throwaway MVPs still get more leverage from Next.js.

The Future is Modular, Not Monolithic

Modular frameworks like Vike are not a quirky side path; they are the logical next step after a decade of monolithic React tooling. As apps have grown, the “one framework to rule everything” model has started to crack under the weight of real-world complexity, performance budgets, and long-lived codebases.

The rise of Vike, Astro, and TanStack Start points to a clear demand: developers want composable primitives, not bundled religions. These tools share a bias toward small cores, opt-in features, and explicit wiring instead of magic folders and global conventions.

Astro popularized the idea of islands and zero-JS-by-default pages. TanStack Start builds around data-layer control and routing primitives instead of a kitchen-sink runtime. Vike pushes this further by letting React, Vue, and Solid coexist in one app, on one page, without adapters or hacks.

That modularity unlocks practical wins. You can migrate a legacy React section to Vue incrementally, experiment with Solid in a single island, or run multi-tenant frontends that customize stacks per customer without rewriting the platform.

Control does not mean going backward on capabilities. Vike still gives you modern SSR, SSG, and edge deployment via Photon, plus client bundles that often sit in the 10–15 kB range instead of the 70–100 kB you see in many Next.js builds. You decide per page whether it’s SSR, SSG, or entirely client-side.

Stability is part of the pitch. Vike’s “boring” MIT-licensed core does not chase React Server Components every six months, which matters if you plan to keep a product alive for five or ten years instead of one funding cycle.

If Next.js feels like it’s fighting you, follow the video’s advice: spin up a side project with Vike. Wire a couple of pages, deploy with Photon, mix in an island or two, and see whether a modular future actually feels better in your hands.

Frequently Asked Questions

What is Vike and how is it different from Next.js?

Vike is a modular, Vite-based meta-framework that provides core SSR/SSG capabilities without the opinionated, all-in-one structure of Next.js. It prioritizes flexibility, control, and performance, allowing developers to choose their own tools and architecture.

Can I use React, Vue, and Solid in the same Vike project?

Yes. One of Vike's main features is its framework-agnostic UI layer. You can use React, Vue, Solid, and other frameworks together in the same application, even on the same page, using an 'islands' architecture without special wrappers.

Is Vike ready for production in 2025?

Vike is considered stable and is used in production by various companies. However, its ecosystem is smaller than Next.js, meaning you'll need to assemble more parts like auth and image optimization yourself. It's best suited for experienced teams who value control and long-term stability.

What are the main drawbacks of using Vike?

The main drawbacks include a smaller ecosystem, fewer built-in features (it's not 'batteries-included'), and a steeper initial learning curve as you must wire up data fetching and other logic yourself. The documentation can also be less comprehensive than Next.js for advanced use cases.