Next.js is infuriating

Next.js Complexity and DX (Developer Experience) Issues

A significant portion of the discussion revolves around the increasing complexity of Next.js and its impact on developer experience. Many users express frustration with opaque error messages, difficult-to-debug issues like hydration problems, and a general feeling of not understanding how the framework operates.

"j-krieger" states, "But whenever I work with Next, I feel like we lost the plot somewhere... I can’t even count the hours I spent with weird hydration issues."
Responding to a Next.js developer's comment about middleware, "throwaway150" expresses, "That makes it sound as though the answer to a clumsy logging facility is simply to add another heavy layer of complexity. Surely not every application needs OpenTelemetry. Why can’t logger().info() just work in a sensible way?"
"palmfacehn" notes, "Perhaps it makes sense to the advocates, but for those of us not on the bandwagon, it can be sincerely baffling."
"eknkc" recounts, "We built a pretty large app on Next and it was painful from start to finish. Every part of it was either weird, slow, cumbersome or completely insane."
"csomar" opines, "Anyone who is running back-end code in Next.js has no idea what they are doing. It could be acceptable if it is a toy project and you want to get something quickly but even for a small operation or MVP, the whole thing is not coherent."
"sarreph," while defending the App Router, acknowledges the general sentiment: "And yet, people generally like to shit on Next.js I sense because they haven't taken the small amount of time investment required to actually just understand it."

Logging and Observability Concerns

A specific pain point highlighted in the discussion is the difficulty of implementing basic logging and observability features in Next.js. Users feel that these essential aspects are not first-class citizens and require significant configuration or the adoption of heavy, enterprise-level solutions.

"Etheryte" asserts, "The fact that you have to even think about how to get logs out of your application is insane, never mind all the hoops you need here. Logging should be a first class citizen in anything that goes to production."
"pjmlp" counters, "Interesting, because that is hardly so in most frameworks, logging requires additional libraries and configuration almost everywhere."
"throwaway150" reiterates the sentiment against the proposed solution: "That makes it sound as though the answer to a clumsy logging facility is simply to add another heavy layer of complexity. Surely not every application needs OpenTelemetry. Why can’t logger().info() just work in a sensible way? This can't be such a hard problem, can it? Every other language and framework does it!"

API Churn and Inflexibility

Several users point to the frequent changes in Next.js's APIs, leading to instability and making upgrades difficult or painful. This churn is seen as a significant issue, especially when compared to more stable frameworks.

"adamddev1" expresses frustration: "I have been frustrated with Next.js changing it's API so much in the last few years and making things more and more complex and confusing."
"eknkc" warns, "If you don't like changing APIs I'd stay away from the Remix guys. I know it is not like Next but I've used react-router, which had some API churn, later evolved to remix and then back to react-router... Backward incompatible changes are the signature of it."
"thiago_fm" compares Next.js to Meteor.js, stating, "Similar to Meteor.js, they've tried to abstract things that aren't really abstractable... It handles edge-cases extremely poorly, and when you have those scenarios, you either need to find a workaround (so code becomes ugly and painful to maintain) or give up."
"DanielHB" offers a broader perspective: "But these solutions keep coming up because they bring one thing: Self-contained / "batteries included". Just the other day there was a thread in hackernews about Laravel vs Symphony and it was the same thing: shit breaks once complexity comes in."

Architectural Complexity and Abstraction Layers

The underlying architecture of Next.js, particularly its approach to server-side rendering, edge functions, and the interplay between client and server code, is a recurring theme. Many feel that the layers of abstraction, while intended to offer advanced features, ultimately lead to confusion and difficult-to-manage systems.

"Vinnl" explains the shift: "The previous model was that you simply have code that runs on a server when a request comes in, sends a response to the client, and then the code in that response is run on the client. Instead, now we have a situation where some bits run on the server, some of them on the client, which call out to some bits on the server again, and all of this can happen either before or after the server started sending the response." He concludes, "Which is kinda neat, but also massively complicates the mental model."
"solatic" ties these issues to specific contexts: "Next.js has layers upon layers upon layers due to the interplay between the browser, middleware, edge vs. node, SSR... It's an enormous amount of complexity and it really only fits under the following set of circumstances:..."
"csomar" argues, "My opinion remains the same: Most of the issues in Nextjs are not a bug but a feature. A feature that only functions and locks you in Vercel platform."
"lmm" believes, "They're trying to do something that's fundamentally very hard. Unifying server-side and client-side code was always going to cause confusion when the difference becomes relevant."
"ollysb" criticizes the App Router's design: "When they transitioned to the app router it was like they'd given some bootcamp graduates a crack at "improving" on the express apis - which are mature and roughly align with the composable russion doll approach taken in servlets, rack, plug and any other server interface I've ever seen."

Niche Use Cases and Vercel Lock-in

Some participants suggest that Next.js, and by extension Vercel's hosting platform, is best suited for specific types of projects, implying that its complexity and cost may not be justified for general web development. Concerns about vendor lock-in are also present.

"solatic" outlines a restrictive set of circumstances: "You sell a B2C product to a potentially global audience, so edge semantics actually help with latency issues... You're willing to pay Vercel a high premium for them to host... You have no need for background task processing (Vercel directs you to marketplace/partner services), so your architecture never pushes you to host on another provider."
"UK-Al05" directly states, "Next.js is marketing to get you locked into vercel hosting."
"csomar" reinforces this, concluding, "Most of the issues in Nextjs are not a bug but a feature. A feature that only functions and locks you in Vercel platform."

Alternatives and Preferences

The discussion also features users who prefer or advocate for alternative frameworks and approaches, often highlighting their perceived simplicity or better DX.

"pjmlp" initially praises Next.js: "Next,js is the only sane frontend framework followed by Angular." However, this is immediately challenged.
"bob1029" strongly disagrees with the praise for Angular: "Angular is absolutely not a sane framework. I'd argue it used to be, but you can't build trust in anything after being rugpulled with 4+ major breaking refactors over the years."
"j-krieger," a React defender, finds Next.js problematic: "But whenever I work with Next, I feel like we lost the plot somewhere."
"palmfacehn" prefers a minimalist approach: "Personally I prefer to minimize my exposure to JS by decorating traditional HTML+CSS documents with vanilla JS as needed."
"zwnow" finds Vue to be a positive experience: "I work with Vue 2 and Vue 3, both options and composition APIs and both are pretty great."
"b_e_n_t_o_n" contrasts Next.js with Remix: "Remix ... is like the polar opposite of this, it's just a Request -> Response handler that you have to build your server around manually. Which I found kind of annoying at first but it does give you the freedom to do what you want."
"tiku" finds success with Inertia.js and Laravel: "React with Laravel made my work so much simpler. Routing through Laravel was easier for me. The data sharing from Laravel to the frontend is painless. I also like the server side, PHP works better for me than a Javascript server."
"solatic" advises, "Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR."

Node.js Ecosystem Criticisms

Beyond Next.js, some users broaden their critique to the Node.js ecosystem itself, citing fragmentation and perceived weaknesses in performance and stability compared to other backend platforms.

"thiago_fm" states, "The only reason it is successful is that everybody knows JS/TS. But just because everybody knows it is rarely a reason to use it... Node.js a terrible platform for server-side in comparison to Java/C#(performance/stability) & Ruby/Python(dev speed)."
"thiago_fm" also remarks on alternatives: "I'll extend my feedback about Node.JS backend. Look how many flavors: deno, bun... It's a mess."
"balamatom" offers a counterpoint: "For example, I've found Node to do what Python does, only better. For example Node does dependency resolution without involving the OS package manager."

The "Batteries Included" vs. Buffet Debate

A recurring theme is the trade-off between "batteries included" frameworks, which aim for a more integrated and opinionated experience, and the more modular "buffet-style" approach where developers assemble their own toolchains. Next.js is seen by some as leaning too heavily into the former, leading to inflexibility.

"DanielHB" articulates this: "This approach has many disadvantages but it really keeps things flexible and avoids tower-of-babel style over-engineering... It is understandable why "batteries included" is so popular, it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other."
"sarreph" defends Next.js's "batteries included" nature: "It's as close to a "batteries included" (such as Rails or Phoenix) system that the JS ecosystem has."

Nostalgia and Simplicity

Some users express a longing for the days when web development was perceived as simpler, contrasting it with the current complex landscape. This sentiment is often tied to older technologies like Perl and CGI.

"pjmlp" invokes this: "Saying this as someone doing Web related development since 1998, glory days of Perl and CGIs."
"Jnr" finds renewed joy: "Nextjs and React gave me back the joy to develop web frontend again."

The Role of Hype and Trends

A few commenters suggest that the adoption of certain technologies, including JavaScript frameworks, is driven more by hype and trends than by sound technical reasoning.

"thiago_fm" laments, "Unfortunately companies adopt programming languages based on hype and trends, rather than technical reasons."