Next.js is infuriating

Posted by Bogdanp 9/2/2025

1029 points | 578 commentspage 5

quadhome 9/2/2025|

AsyncLocalStorage.enterWith is the wrong method; .enterWith changes the logger for across the *synchronous* execution. This doesn't matter if there's only one request happening at time-- like when you're testing locally. But that's why it didn't work on the actual project.

Use .run.

  return LoggerStorage.run(requestLogger(), () => {
      logger()?.debug({ url: request.url }, "Started processing request!");
      return NextResponse.next();
  });

huksley 9/2/2025||

I have enterWith working perfectly with async/sync flow - all operations between request and response are logged with request id transparently. I am using custom server for both standalone build & dev server, nextjs 14, node 22.

dminik 9/2/2025||

Nope, this doesn't work either.

UK-Al05 9/2/2025||

Next.js is marketing to get you locked into vercel hosting.

poisonborz 9/2/2025|

Using nextjs for years without paying a cent to Vercel. If you want React SSR, why would you create a DIY solution if there is a framework with huge community and support?

recroad 9/2/2025||

I feel a poor tool choice for your use case should not give you the right to blast the tool and it's design decisions. Most of those complaints are resulting from not understanding how NextJS works and the design decisions that it's creators have made. For example, the middlewares. they're to be treated as a hook. If NextJS had a mechanism for having handlers like Express does, you'd have complained about handler execution order or something.

If you picked NextJS without knowing how it structures its middleware, the vendor lock-in to Vercel, its SSR strategy, its hydration schemes etc. that's on you. I, and many others, have had a lot of success with NextJS increasing delivery speed and ultimately, customer value.

Two years ago I moved off of the React ecosystem to Elixir/Phoenix/LiveView, and it's been great. But that's had its own challenges stemming from the design decisions its creators have made. You're always going to be running into things that you don't like, and I feel NextJS has just become an easy target for people who are looking to vent.

fabian2k 9/2/2025||

NextJS has been pushed aggressively by many people and often recommended as a kind of default for React applications. Which I consider a bad idea, in a large part because NextJS contains a lot of complexity that most applications don't need.

agos 9/2/2025||

the React documentation is infamously responsible of recommending Next as a "default". After a lot of backlash it got somewhat toned down, but it's still the first thing they suggest[1] for creating a new app

[1] https://react.dev/learn/creating-a-react-app

dminik 9/2/2025|||

I'm sorry, but please do read the post.

The middleware section is a setup. The real trouble starts when ejecting from Next and using a custom server still doesn't allow you to do anything because Next is a black box.

I would have been happy with installing fastify and just using it's middleware, but even that doesn't work.

FredPret 9/2/2025||

What challenges did you pick up with Elixir?

recroad 9/3/2025||

Elixir/Phoenix is awesome, no complaints overall. A few small things:

- Passing data from LiveComponent's/JS is a bit of a pain (need to use update())

- phx-hook doesn't always pay well with re-rendering state changes

- Directly calling JS functions (e.g, getting Apple Pay to work) isn't clean

- Can't use attr when using LiveComponents (need to wrap them in a functional component)

- Unique ID requirement for LiveComponent is a pain (so is wrapping them in a div)

- No great APIs for updating session data when using sockets

- Can't pass params to LiveView in live_render, have to use session

Demiurge 9/2/2025||

Maybe this is a good place to ask... but I was actually considering Next.js as a replacement for Gatsby.js project that is a few years old, but is growing at a steady pace. Given all the negative sentiments, what are better alternatives? I don't even use any SSR, or GraphQL capabilities. The main thing I liked about gatsby vs previous "bring your oown library(router)" are: very little configuring, nice dev server, easy to use plugins. It just solved many of the boilerplate tasks for me, and let me get on with react.js components, hooks, etc. I use Django backend for API, and static hosting for the frontend.

Potential alternatives I've found:

  * astro
  * remix
  * back to react-router... and there were multiple back when I used it! :(

Update: after some research, I really Tanstack router approach: https://tanstack.com/start/latest

theSIRius 9/3/2025||

We've started a Tanstack Start project at work for a green field project, and it is honestly a mixed bag. It took a lot of trial and error to get the whole project working - the server parts were working without an issue, but there was no client hydration. After some debugging, we have found that there was an error being thrown during data preload which took down the hydration process. No errors were emitted, and the docs weren't were helpful at all.

But once we got that out of the way, it is pretty nice to work with. The FE developer is very happy with how fast the project is and how easy it is to just peek into the BE portion and understand it. Server functions are just so nice to use and everything gels together really well. But it's still early days though. I would only recommend it if you are OK with parsing not-really-great documentation and maybe some relevant GitHub issues from time to time.

Demiurge 9/3/2025||

Thanks for sharing! :)

mpeg 9/2/2025|||

FYI remix doesn't really exist anymore, it was folded into react-router a while back.

Astro I've found to be pretty solid for prototyping, I like that it gives you control over the rendering of client side code islands and that it works with multiple rendering libraries. I don't love some of the direction they've taken lately though, and I worry that it will become bloated with things like astro db

soiltype 9/2/2025|||

I've rebuilt multiple gatsby projects in NextJS recently, and mostly it's actually been pretty nice. However, the crazy high level of abstraction and black-boxing does mean occasionally we run into bugs caused by undocumented behavior and have no idea what is the right way to handle them.

Demiurge 9/2/2025||

Hmmmm, that sounds like it would work, but is also a bit concerning :) I’d rather not have some mystery bugs, and considering all the open issues in GitHub…

hungryhobbit 9/2/2025||

Say anything negative you could possibly say about Next ... and it will apply a thousandfold to Gatsby.

Likewise React Router is ... the example I use when I want to tell someone about a terribly engineered library. As you said, there are multiple React Routers, because the developer is completely incompetent, and has no idea what he is doing. As a result, he changes the entire library in massive, backwards-incompatible ways ... EVERY. NEW. VERSION.

Astro and Remix are viable options, but there's a reason why Next (despite it's flaws) remains dominant over them.

jakubmazanec 9/2/2025|||

React Router v4 was released in was released in March 2017 (more than 8 years ago!). v5 was released in May 2019 with no API changes. v6 was released in November 2021 with a new API based on React hooks (this API was much better than the previous). v7 was released in November 2024 with the "Remix" APIs (most importantly the "framework mode"). So, the gaps are 4 years and 3 years - that's doesn't seem that crazy.

I personally updated Remix v2 project to React Router v7 and because I used various flags to prepare for the upgrade, it was done without any issue and fairly quickly.

> entire library in massive, backwards-incompatible ways ... EVERY. NEW. VERSION

So a new major version has some breaking changes? Why is that surprising?

Demiurge 9/2/2025|||

Any thoughts on the Tanstack libraries? We use their query library, and ironically, it reminds me of ext.js tiny bit, but it's been pretty consistent.

tiku 9/2/2025||

Through a customer I've come into contact with InertiaJS. 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. I've had some weird bugs with nodemon, pm2 and other server tools.

jeppester 9/2/2025|

I also recommend inertia.

It really doesn't do much, which is very refreshing coming from Nextjs.

It's simple tooling for backend for frontend-style APIs, taking care of basic routing, fetching of data, and submitting forms.

While inertia was invented for Laravel, I'd argue that it works even better with Adonisjs. Because Adonisjs is TypeScript you can infer the types coming from the backend.

0xblinq 3 days ago||

+1 for this stack.

Adonis + Inertia works wonderfully well. It's the best of both worlds. And the simplicity of this architecture is something to admire. It's very easy to know what's going on at every point: It's just requests, responses, middlewares and routes/views. Simple and easy, while still super powerful.

BoredPositron 9/2/2025||

Can't wait for the opinionated fork that gets abandoned in 3 weeks.

mfrye0 9/2/2025||

Adding on to the other comments here about Next.js vs Remix.js.

We had to choose a framework for our new app last year and were researching the current state of things. Next.js was / is by far the most popular, but also had some of the worst feedback and caution to stay away. Remix isn't perfect, but I appreciate less abstractions and working with simple request / response structures.

Also, a warning for those hiring for frontend / fullstack roles:

Over the years when hiring for roles for X frontend framework, we would constantly find "experts" in framework X that would really impress us. Whether it was React, Angular, Vue, Remix, etc. Then after moving forward, we found they didn't know core JS fundamentals and were basically useless beyond the framework.

jakubmazanec 9/2/2025||

As others have noted, if you need a React framework, React Router v7 (in framework mode) is much better than Next.js. I would argue it's a great framework. No over-abstractions, just React on top of standard web technologies.

Don't be scared by the complaints about previous breaking changes (which BTW are inevitable when we still haven't figured out the best approaches to the server/client app architecture) - React Router's current strategy using various flags [1] allows you to prepare for breaking changes well in advance.

[1] https://reactrouter.com/community/api-development-strategy

lagrange77 9/2/2025||

I can only recommend vike.dev .

nickdichev 9/2/2025|

I wish more people knew about and were talking about vike, really powerful tool

brandly 9/2/2025|

He made a whole new blog to complain about Next.js and built the blog with Next.js

stronglikedan 9/2/2025|

Sounds like he writes from experience.

More comments...