Next.js is infuriating

Posted by Bogdanp 9/2/2025

1030 points | 579 commentspage 11

zallarak 9/2/2025|

Agreed. I've run into so many issues with documentation and sane defaults, and the Vercel team response is to always gaslight you into thinking you've done something wrong.

The truth is, its just poorly designed software.

Where it shines is batteries included for getting started. They realized if you have low activation energy requirements, you will win a critical mass of people who put up with your crap. A good metaphor for devtools overall.

jhaile 9/2/2025||

Given all of the NextJS hate on here, I feel like I'll get downvoted for saying this...but we run Next.JS, don't host on Vercel - and really don't have many problems at all.

That being said, our app is largely built like a standard React app, we aren't using much server-side-rendering, and we use TanStack Query for loading most data. So, the main value of Next.JS is mostly just the routing and project organization.

abustamam 9/2/2025|

Out of curiosity, have you tried out Tanstack Start? It appears to be a framework similar to next and remix/react router.

I've loved all the Tanstack libraries so I'm looking for an excuse to use Start lol.

graphememes 9/2/2025||

I think Edge infra and SSR irks me the most out of everything.

xkcd1963 9/2/2025||

The slow response time on hithub is most likely due to layoffs

wg0 9/2/2025||

Genuine question - What are the alternatives?

React Router + Express?

Or something else?

nobleach 9/2/2025||

We do React Router 7 (previously Remix) with Fastify for a couple of our apps. Both external and internal. I'm really happy with the dev experience. We also have plenty of NextJS floating around here too. Most teams use it as a "better Create React App". There's little use of any of its features. I'm the only one that's used any server-side stuff.

For my team, React Router 7 just gets out of the way. If you use it in framework mode (SSR) you will have loaders and actions, which are things that run on your server. I find it SO much less convoluted. The logger example from the article above is childs play in React Router. Either import your logger and run it in your loader. (You may want to add .server.ts to make it explicitly ONLY server) or inject the logger via context.

cluckindan 9/2/2025|||

React Router v7 is actually awesome and can do SSR if you need it.

chrisweekly 9/2/2025|||

React Router is great. Express is ok for its server (hono or fastify have advantages).

gitaarik 9/3/2025||

Sveltekit

notyouraibot 9/2/2025||

NextJS as a framework is pretty good, it has gone downhill since the whole RSC shift sure but its still pretty good for most use cases. The problem however is Vercel and how closely its tied to Vercel.

I recently developed a small internal application in NextJS and we are using Azure PostgreSQL, we are on the Pro Plan from Vercel (honestly even that's an overkill, our use case would be satisfied easily on the free plan; which is very very generous) but one problem I faced is a NextJS App hosted on Vercel, it will never have a static fixed IP, so we couldn't directly access our database unless ofc we opened it to the entire world, which is never an option. This is so dumb honestly, the audacity to call it a full stack framework is stunning.

rustystump 9/2/2025||

The feeling in the article is one i share. Frustration. It stems due to the rush job that is endemic to nextjs when it comes pushing out half baked features. It started with the app router.

Case and point

“Use server” “Use client”

Intuitively, one runs on server and one on client. But you would be wrong. It is far more complicated. Now multiply this by 100 features. What you get is an obtuse hard to penetrate framework that seems to behave unpredictably unless you carefully read the thousands of pages of docs.

Now ai doesnt help as the api changes so frequently that it often spits out version 13 and not 14.5 let alone 15 or whatever is most recent.

This likely happens due to the need to rush features out for the next nextjs conf much like many other saas providers rush for their respective conf.

mkl95 9/2/2025||

Most of the modern frontend ecosystem is infuriating. The early React + Typescript era was mildly upsetting but bearable, and it hinted at a relatively nice future if abstractions improved. Then Vercel et al threw that slow progress into an overpriced garbage can.

kadhirvelm 9/2/2025||

Well the thing that’s infuriating for me is feeling like there isn’t a good, well supported alternative for writing an enterprise grade React app that will be continue to be around. I used to rely on create-react-app, but now that that’s deprecated, I often find myself asking what else can I actually rely on? I don’t want to spend eng cycles dealing with webpack and stuff, this seems to be what the React team is endorsing so I guess I’m stuck?

Another thing I don’t know how to think about is the target market for nextjs seems to overlap with Ruby on Rails, a lot of e-commerce, media, etc. And most of these B2B apps I write are certainly not that…

worldsayshi 9/2/2025|

What about vite.js?

One of my latest experiments was using vite.js and then using a go backend where I embedded the vite app using embed.FS. I haven't tried it in a live environment yet but it seemed like a potentially nice way of doing it.

tjpnz 9/2/2025|

Anything related to observability with Next.js is guaranteed to be a fucking nightmare. At work we'll typically implement a metrics endpoint for Prometheus - really trivial for just about every API or fullstack framework under the sun, except Next.js. I think I gave up at the point where the suggested method was using a custom server (negating some of Next.js's supposed benefits), or adopting Vercel's proprietary metrics service which wouldn't have helped us anyway. Terrible, terrible stuff - would never touch again.

More comments...