My full-time job is working as a front-end web developer for a Next.js project. I’ve been working on the project for close to four years now. If I were able to be the framework choice-maker for the company’s next big project, I would choose anything but Next.js.
Dominik Meca
Next.js Is Infuriating
I don’t know. For me, personally, I don’t want to use Next.js anymore. You might think that this is just a singular issue and I’m overreacting. But there’s bugs and edge cases around every corner. How did they manage to make TypeScript compile slower than Rust? Why make a distinction between code running on client and server and then not give me any tools to take advantage of that? Why? Why? Why?
clover caruso — paper clover
One Year with Next.js App Router — Why We’re Moving On
As I’ve been using Next.js professionally on my employer’s web app, I find the core design of their App Router and React Server Components (RSC) to be extremely frustrating. And it’s not small bugs or that the API is confusing, but large disagreements about the fundamental design decisions that Vercel and the React team made when building it.
Harshal Patil — Medium
Why Next.js Falls Short on Software Engineering
I have reservations against using or recommending Next.js as a general purpose framework for React projects. If I do so, then I feel I am not doing justice to software architecture. I wrote about my challenges 3–4 years ago after adopting it for many products.
What I’ve come across with Next.js is the carelessness when it comes to stability and iterative progress, like the tendency to use React canary code in “stable” releases, that sudden switch to a half-baked app router, the lack of basic web standard support, and a focus on supporting their own infrastructure to the detriment of other hosted options. Vercel’s choices feel hostile to the open source community. Next.js feel fundamentally dated by the choices made by React. React probably made a lot of sense when it was first made; I’ve heard enough horror stories of working on the native DOM to know that I probably would’ve welcomed the idea of React when it first premiered. But in practice I feel like React is just too big for most projects and unnecessarily complex for basic interactivity on a page; it feels like I’m having to worry about both the real DOM and the virtual DOM, especially with the way React Server Components work.
Mayank
React Server Components: the Good, the Bad, and the Ugly
I debated not publishing this post because of the way the React community has historically handled criticism. It is only recently that I decided it is important to share my thoughts, especially after seeing that much of the existing criticism is either not well-documented or stems from unfamiliarity.
For most projects I think Next.js would not be my first or even second choice. I think smaller and simpler frameworks or tools are a better fit for most projects; few of us really need the type of system that Meta needs for Facebook. Most of the ex-Next.js users seem to be pushing for Vite and Tanstack; I just want something that isn’t Next.js.