I hope this isnt the way that React as a whole will go in the end.

But fortunately there are enough alternatives about.

I won't repeat what the sibling poster said, but I can tell you, I've been using NextJS from v12-v15 and in that time we've had:

- The catastrophic (and, at the time, UNDOCUMENTED) "aggressive, opt-out caching of all fetch calls", which confused the living daylights out of everyone who suddenly couldn't retrieve updated data from their servers. Like, don't override a native JS function that's supposed to work in an expected way, with black-box magic that adds caching behaviour that then needs to be overriden _per route_ with directives on each route. Cache headers can be added to fetch calls and are easy to configure globally via axios if needed. If you're going to do black magic, call it "nextfetch" or something

- The app router / page router transition was shockingly badly handled, with so much missing documentation around dynamic routes

- I don't know how many different ways of fetching / setting metadata / <head>-related techniques I've had to learn by now. It seems to change all the time. BUT, that isn't the worst part....the worst part was / is:

- You couldn't, for the longest time, fetch metadata for a page without duplicating fetch requests. I think this is where their fetch-deduping thing came from. But again, black-box magic on a native JS function with very inconsistent behaviour, so for a while, all pages in our app just had to make two fetch calls per page that needed specific metadata added to the <head>

- Vercel as a platform not allowing to set billing limits (have fun with your DDoS that they don't recognise as such)

- Middleware is one file. That's what you get. No chaining, nothing. One god-function for everything. Just think about the anti-pattern that is

- I don't know whether it's clever or terrible, but if you want to add a sitemap, you do so by defining a route by creating a folder called sitemap.xml (yes, a directory), where you then put your route.ts which is in keeping with the way the new router should work. But somehow it just doesn't sit right with me. Folders with file extensions. But it also adds a lot of ability to make the sitemap highly customisable and dynamic, so maybe it's ok

- You suddenly needed to start awaiting url params, cookies, etc. which is sort of fine, but was a huge change causing warnings all over the compiler for months and months

Anyway, those are just a few things off the top off my head. I already find React to be quite counter-intuitive and non-deterministic, but NextJS just adds a layer of pain on top with very, very few advantages.

I am dying to get my hands on an alternative, but also don't want to rebuild all of the apps I built when I was still optimistic about NextJS.

- inconsistent behavior between hosted and self hosted versions of the same code

- horrible build times, like laughably bad multi-minute builds for trivial code bases

- crappy directory based routing system with lots of weird gotchas

- schizo identity JAMstack -> serverless -> ssr -> now its microvms + ai

- multiple hilariously long running GH issues where the dev team is thrashing around trying to debug their own black box framework

- "framework" that barely provides any of the primitives necessary to build web apps

- major breaking changes around core features like routing that require painful migrations

- general sloppiness, churn, and insecurity that comes from being part of the nodejs ecosystem

Thats not even getting into all of the shady patterns vercel uses to lock you into their overpriced hosting.

I've been a part of multiple teams that decided to build apps using NextJS, and while the FE is not my responsibility I typically got pulled in to help troubleshoot random issues. It was a complete waste of time in almost every case, and in one case resulted in the entire FE team being let go because they were unable to ship anything on time.