Next.js has been one of the most powerful React-based frameworks for both frontend and backend development, especially throughout 2021–2024, and arguably even today.

However, there were several issues that eventually made me reconsider using Next.js as my primary framework:

Development experience (especially slow development mode)
Confusing caching behavior
Vercel and ecosystem lock-in
CVE-2025-66478

1. Development Experience

When building a very simple Next.js project, such as a landing page, many developers may never experience this problem. However, things can become different as an application grows more complex.

Imagine working on a large application, such as an e-commerce platform, with hundreds of components, routes, and API endpoints. You make a small change to the code, save it, and then refresh the browser.

For me, sometimes even a hard refresh could take nearly two minutes before the application was ready again.

This was a major frustration during my development experience with Next.js, particularly from late 2024 throughout 2025.

The problem was not necessarily that Next.js could not handle large applications. The problem was that the development experience became increasingly frustrating for me as the project grew.

2. Confusing Caching Behavior

Caching was another issue I encountered, both during development and in production.

There were situations where I explicitly implemented caching, but the system did not seem to cache the data as expected. Other times, something that I did not intentionally configure to be cached appeared to behave as if it was being cached.

This made debugging particularly frustrating because I sometimes had to ask myself:

Is this a bug in my code, or is Next.js caching this somewhere?

Understanding exactly where data was being cached, revalidated, or served from became more complicated than I expected.

3. Vercel and Ecosystem Lock-in

Another factor was the growing Vercel ecosystem around Next.js.

Vercel provides many useful services, including:

Vercel KV
Vercel Blob
Vercel Postgres
Vercel-specific caching
Vercel Functions
Vercel Edge Functions
Vercel Cron
Vercel Analytics

There is nothing inherently wrong with these services, and many of them are genuinely useful.

However, I personally started to feel uncomfortable with how many parts of my application could become tied to a specific ecosystem.

The more platform-specific services I used, the more I had to think about portability.

I wanted my application architecture to remain relatively independent from my hosting provider, so moving to another platform would not require replacing large parts of the infrastructure.

This was not the main reason I left Next.js, but it definitely contributed to my decision.

4. CVE-2025-66478

The event that pushed me even further toward looking for an alternative was CVE-2025-66478, which was disclosed in December 2025.

The vulnerability affected the React Server Components (RSC) protocol and could allow remote code execution (RCE) in vulnerable Next.js applications.

The vulnerability originated from the upstream React implementation and affected Next.js applications using the App Router and React Server Components.

According to the Next.js security advisory, the affected versions included:

Next.js 15.x
Next.js 16.x
Next.js 14.3.0-canary.77 and later canary releases

Stable Next.js 13.x and 14.x releases were not affected by this specific vulnerability.

The vulnerability was particularly concerning because successful exploitation could potentially allow an attacker to execute code on the server. For applications with sensitive environment variables or other server-side secrets, this could potentially put those secrets at risk.

The vulnerability was fixed in several patched releases, including Next.js 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7.

For me, seeing a critical vulnerability involving the RSC ecosystem was the final push I needed to seriously reconsider my framework choice.

It was not simply:

"Next.js has a vulnerability, so I should leave."

Rather, it made me reconsider whether the complexity and ecosystem around Next.js were still worth it for the kinds of projects I was building.

Finding Svelte

After all of these experiences, I started looking for an alternative.

That was when I discovered Svelte and SvelteKit.

I did not switch because I believed Svelte was objectively better than Next.js. Next.js is still an extremely capable framework, and it makes a lot of sense for many types of applications.

I switched because Svelte's approach felt more natural to me.

The framework felt simpler to reason about, the development experience felt lighter, and I found myself spending less time fighting the framework and more time actually building my application.

In the end, switching frameworks was not really about finding the best framework.

It was about finding the framework that felt right for me and the way I build software.

2026