Next.js is infuriating

I'm so glad I'm not the only one thinking this. I built a medium-complexity, money-making, production-grade app in Next.js and started out on Vercel's hosting (and Google Firebase) and then moved to hosting myself and stripping out Firebase, replacing it with Pocketbase.

Pocketbase was the ONLY good thing about this journey. Everything else sucked just so terribly.

Infinite complexity everywhere, breaking changes CONSTANTLY, impenetrable documentation everywhere.

It is just so, so awful. If we rewound the last five years of FE trends and instead focused on teaching the stuff that existed at the time properly, we'd be in a much better position.

I've also built a very complex React frontend (few thousand users, pretty heavy visual computation required in many places). And while I don't particularly like React either, Next.js was even worse.

And lastly, built a CMS in Go, with vanilla JS. And while the DX sometimes feels lacking, I just can't help but feel that I actually know wtf is going to happen when I do something. Why is that so hard?

In React and Next.js I am STILL, AFTER SIX YEARS constantly guessing what might happen. Yes, I can fix just about anything these frameworks throw at me, thanks to all the experience I've gathered about their quirks, but it all just feels to messy and badly designed.

In Go, the last time I guessed what might happen was in the first six months of learning it. No surprises since. Codebases from years ago are still rock-solid.

Why can't we do this at the frontend, goddammit?

My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting

> I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else.

Things will get far worse before they get better. Right now, online courses such as the ones in PluralSight are pushing Next.js on virtually all courses related to React. I have no idea what ill-advised train of thought resulted in this sad state of affairs but here we are.

I've been running a SaaS on Next.js + GraphQL for 4.5 years now, sticking to Pages router has eliminated most of the complexity.

I recently rewrote my auth to use better-auth (as a separate service), which has allowed me to start moving entirely off Next.js (looking at either React Router 7 or Tanstack Router).

Back when I started, Next.js made server side rendering incredibly easy, but it turns out I didn't need it. My marketing site is entirely static, and my app is entirely client rendered.

Second worst for me. I’ve used Sharepoint.

Yes, and even if you manage to work around its profoundly silly limitations—seriously who designed the new routing nonsense and have they ever made a website before—every time you go to upgrade the new version breaks everything.

By comparison, DIY SSR with Express takes a few days to get working and has run quietly for multiple projects for years on end.

Sounds like Javascript's answer to Spring.

Many of the abstractions and nextjs tools do things that my OS does better, cleaner and more predictable too.

I suppose the overly complicated ENV/.env loading hierarchy is (partly) needed because Windows doesn't (didn't?) have ENV vars. Same for inotify, port detection, thread management: *nix does it well, consistent ish. But when you want an interface or feature that works on both *nix and windows, in the same way, you'll end up with next.js alike piles of reinvented wheels and abstractions (that in the end are always leaking anyway)

I wouldn't say I agree with those circumstances, but even if they did indicate a match with Next.js, they are not worth the reduction in productivity and maintainability that comes with it.

I use Gleam's Lustre and am not looking back. Elm's founder had a really good case study keynote that Next.js is basically the opposite of:

https://www.youtube.com/watch?v=sl1UQXgtepE

Vercel is the cancer of the modern web. The claw into every framework ecosystem and abuse them as sales funnels for their paid plans, pretending they care about open source, competition, and the web.

And even if you fall under the first category, I find it hard to believe that the performance bottleneck is solved by using Vercel and SSR.

With all the other crazy shit people are doing (multi-megabyte bundle sizes, slow API calls with dozens of round-trips to the DB, etc) doing the basics of profiling, optimizing, simplifying seems like it'd get you much further than changing to a more complex architecture.

> Half these issues stem from a relative misunderstanding of exactly where the code is running.

I used to think Javascript everywhere was an advantage, and this is exactly why I now think it's a bad idea.

My company uses Inertia.js + Vue and it a significantly better experience. I still get all the power of modern frontend rendering but the overall architecture is so much simpler. The routing is 100% serverside and there's no need for a general API. (Note: Inertia works with React and Svelte too)

We tried Nuxt at first, but it was a shit show. You end up having _two_ servers instead of one: the actual backend server, and the server for your frontend. There was so much more complexity because we needed to figure out a bunch of craziness about where the code was actually being run.

Now it's dead simple. If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us.

Yeah this is basically it. Vercel is trying to solve for optimised performance by using a combination of React Server Components, Partial Pre-rendering, Edge servers, streaming, etc. A lot of their seemingly weird design and API decisions basically come down to that. If you need it, it's good that it exists. But you can also go pretty far with doing some ssr in an edge function too.

> so edge semantics actually help with latency issues

Hum... You make an entire app in node, load the UI over react, pile layers and more layers of dynamicity on top (IMO, if next.js didn't demonstrate those many layers, I wouldn't believe anybody made them work), eschew the standard CDN usage, and then want distributed execution to solve your latency issues?

> a relative misunderstanding of exactly where the code is running.

This is the exact problem with the App Router. It makes it extremely difficult to figure out where your code is running. The Pages Router didn't have this issue.

As mentioned somewhere else, these are the kinds of layers SSR frameworks have had for decades, maybe people should learn not to do SPAs for everything.

Am I reading this correctly? They are advocating giving up on structuring code in separate files? Is that a scoping problem that NextJS has, which makes it difficult to use multiple files? Seems like a rather ridiculous statement of a framework to make.

I can’t help but feel some of these decisions are made because it’s what is best for Vercel and not what’s best for the framework.

Appreciate the response. But ...

> Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention

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!

First off, since the sentiment here is really negative, I'd like to say that next.js is actually really good for what it does. You've done a great job at building the software that powers millions of websites at this point.

I think a big part of the negative sentiment derives from the fact that detailed documentation and reference documentation almost non-existant. The documentation mostly tells you what exists, but not how to use them, how they get executed, common pitfalls and gotchas etc etc.

The documentation is written to be easy and friendly to newcomers, but is really missing the details and nuances of whatever execution context a given api is in and does not touch on derived complexities of using react in a server environment etc.

This is a trend across a lot of projects these days - often missing all the nuances and details - writing good documentation is really hard. Finding the balance between making things user friendly and detailed is hard.

Keep it up

Since you're here — I'll just pipe in.

Here in this article, the author, failing to comprehend the domain differences, is applying the same approach to call a function everywhere. Of course it won't work.

The fallacy of nextjs is attempting to blend function domains that are inherently different. Stop doing that and you will be fine. Documentation won't work, it will be just more confusing. Blending edge and ssr and node and client-side into one is a mess, and the attempt to achieve that only results in layers upon layers of redundant framework complexity.

Yeah, I was actually recommended the instrumentation route by a commenter on Reddit.

I spent a similar amount of time setting up opentelemetry with Next and while it would have been titled differently, I would have likely still written a blog post after this experience too.

This isn't your fault, but basically every opentelemetry package I had to setup is marked as experimental. This does not build confidence when pushing stuff to production.

Then, for the longest time I couldn't get the pino instrumentation working. I managed to figure it out eventually, but it was a pain.

First, pino has to be added to serverExternalPackages. If it's not, the OTel instrumentation does not work.

Second, the automatic instrumentation is extremely allergic to import order. And also for whatever reason, only the pino default export is instrumented. Again, this took a while to figure out.

Module local variables don't work how I would expect. I had to use globalThis instead.

And after all that I was still hit by this: https://github.com/vercel/next.js/issues/80445

It does work, but it was not great to set up. Granted, I went with the manual router (eg. not using vercel/otel).

If you finally decided to support proper server-side middleware, why is there still a limitation for only one middleware function and not a chain of middleewares as every other sane server implementation offers?

Will vercel/next come up with an official policy on pages roter/API routes, will they be supported long term? If I start a next project I still use pages/API routes, because of several really really bad experiences with the app router.

[dead]

Thing is I'm spoilt by asp.net, which has so much bad 'stigma' in the (esp startup) dev community but it is _extremely_ well designed.

You get a very batteries included approach(es) but you can always punch out of it and override it. I've never got into a situation where I'm feeling like I'm fighting the framework.

I also really like both Blazor Server and Blazor Webasm which allows you to write the frontend in C# too. Blazor server is great for internal admin panel style apps, and blazor webasm is good for saas apps, and for everything else plain old server sider rendering works great.

I'd really recommend anyone who is annoyed with their web framework to give it a go. It's extremely cross platform now (the huge drawback until about a decade ago was it was very hard to run on Linux, which isn't the case at all now - in fact, it's the opposite, harder to run on Windows), very fast and very easy to use. It takes a while to figure out the mental model of the design in your head but once it comes together you can quickly figure out how to override everything when you hit limitations (which tbh, is pretty rare compared to every other framework).

Nah, Laravel is proof that over engineered abstraction can sometimes be done right. Laravel works beautifully in production and I have never regretted using it.

> If you compare those solutions with the old model that made NodeJS / React SPA get so popular, so fast: Buffet-style tooling/libraries. You basically build your own swiss army knife out of spare parts. Since all the spare parts are self-contained they have to target really low abstraction levels (like React as a component library, HTTP+Express as a backend router, Postgres as DB).

I have done a few Angular apps and the experience/setup quoted above is basically foreign to me. I know that it is a framework and not a library but it is a very well designed framework (atleast Angular 2 onwards; I used Angular v20 for my latest component). Basically most of the commonly needed stuff is included in the framework (I just added NGXLogger for logging) and the abstractions are pretty nice and fairly similar to a backend service (services wrap libraries and components rely on services). RxJS can be a bit of a learning curve but once you are comfortable with the basics, it can take you quite far. Atleast I rarely had to fight with the framework for typical SPAs. Also, the documentation along with tutorials is great - I learned using the tour of heroes application[0] but seems angular.dev[1] is the new home for v20 docs.

[0]: https://v17.angular.io/tutorial/tour-of-heroes

[1]: https://angular.dev/

> it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other

This is my job. We're a small team and my job is to keep things up to date. Insanely time consuming. Packages with hard dependencies and packages that stopped being supported 5 years ago.

> It definitely needs people with more experience to set up everything

I mean it's not just the experience - it's the upfront time cost and then ongoing maintenance.. and for what? It's really easy to underestimate how much effort this will be

Having done both I genuinely think Rails is a 10x productivity boost over stitching your own mishmash of libraries together in Node

The only lack of flexibility you run into is if you really disagree with the fundamentals of the framework. If you hate the ActiveRecord pattern for example you need to stay away

"shit breaks once complexity comes in" is a skill issue

>both over-abstracted and inflexible which made it really hard

This seems to be built into the culture of companies which have those ridiculous whiteboard leetcode interviews. You find people who can produce very clever complex solutions in their sleeep, and then they do that. Interviews aren't selecting for people whose strength is simplicity and clarity instead. So you get a lot of tight loop optimizers and they tight loop optimize everything... not just the tight loops. But if your product is a library/framework being consumed by mere mortals, you probably want something simple if you want to succeed in the long run. The super car's performance is meaningless to you if you can't drive stick.

I'm not a React or Next.js user. Others will disagree, but personally I prefer to minimize my exposure to JS by decorating traditional HTML+CSS documents with vanilla JS as needed.

I was somewhat surprised when I noticed simple Next.js landing pages would break in Firefox. Worse yet, the failure mode was to overlay all of the content with a black screen and white text, "An application client side error has occurred". It was surprising in that a simple landing page couldn't render, but when I discovered that the cause was a JS frontend framework, I felt that it was par for the course.

Perhaps it makes sense to the advocates, but for those of us not on the bandwagon, it can be sincerely baffling.

Next has enshittifed themselves some time ago. Everything that goes through the VC cycle does that eventually.

I am happy for them and their money, but I can't use this anymore. I take Vite as the default option now, but I would prefer something more lightweight.

> But blaming Next.js for that complexity is like blaming a toolbox for having more than a hammer.

The biggest issue is that the complexity is self-inflicted. The term middleware has a pretty well understood meaning if you've worked with basically any other framework in any language: it's a function or list of functions that are called at runtime before the request handler, and it is assumed those functions run in the same process. The fact that Next.js puts it on the edge and only allows one is breaking that assumption, and further, most applications do not need the additional complexity. To go back to your toolbox analogy, more tools mean more complexity (and money), so you wouldn't get a new tool simply because you might need it, you get it because you do need it, and the same applies to edge functionality. If Next.js wants to allow you to run code on the edge before your app is called, that's fine, but it should be opt-in, so you don't need to worry about it when you don't need it, and it shouldn't be called "middleware".

I wouldn't consider this a misnomer, but a really big misuse of the term. Middleware has a long established definition in web applications, so they really should not use the term if they mean something entirely different.

I'm also working with Next.js, app router, and like it very much.

The problem is probably that Next.js makes it very easy to move between front and back end, but people think this part is abstracted away.

It's actually a pretty complex system, and you need to be able to handle that complexity yourself. But complexity does not mean it makes you slower or less productive.

A system with a clearly separated front- and back-end is easier to reason about, but it's also more cumbersome to get things done.

So to anyone who knows React and wants to move to Next.js, I would warn that even though you know React, Next.js has a pretty step learning curve, and some things you will have to experience yourself and figure out. But once you do, it's a convenient system to easily move between front- and back-end without too much hassle.

To people who downvote my comment (and there are many): please elaborate.

I like to learn and improve. A lot of comments here are just baseless negative comments. Please let’s have a real discussion.

Finally someone with a brain.

If learn what is a package/module in python, try to apply that in Go without any brain power, you will complain that Go is bad. If you are using any technology, you should have some knowledge about that technology.

I believe the obsession with streaming is a major factor in the new constraints. Together with supporting the lowest common denominator, edge runtimes.