Why We Ditched Next.js – And Never Looked Back

Next.js has dominated the web development space for years, evolving from Jamstack to server-side rendering (SSR) to microVMs. While this flexibility worked for some teams, we realized that Next.js was no longer the best solution for our needs at Northflank.

1. Performance Bottlenecks

We observed slow rendering speeds (200-400ms per page load), which affected user experience. While Next.js provides optimizations, we found its built-in caching and SSR strategies didn’t scale efficiently for our use case.

2. Constant Shifts in Philosophy

Next.js has gone through multiple paradigm shifts in just a few years:

✅ Initially marketed as a Jamstack framework

✅ Later transitioned into a serverless-first approach

✅ Moved to full SSR and API routes

✅ Introduced middleware-based microVM execution

These rapid changes made long-term adoption difficult—every major update forced significant refactors.

3. Complexity & Vendor Lock-In

While Vercel optimizes Next.js deployments, we found its tooling restrictive when scaling applications across different infrastructure providers. We wanted more control over hosting, deployments, and configurations.

4. Finding Better Alternatives

Moving away from Next.js allowed us to explore alternative frameworks that better suited our real-time architecture. Solutions like SvelteKit, Remix, and custom backend-driven rendering provided greater control, performance, and scalability.

Final Thoughts

Next.js is still a great tool for many developers, but it isn’t a one-size-fits-all solution. If you’re scaling an application and experiencing performance limitations, it might be time to re-evaluate your choices.

Have you faced similar struggles with Next.js or another framework? Let’s discuss better alternatives! 🚀