Next.js is infuriating • Hacker News Board

Re: Next.js is infuriating

#361

Post by hungryhobbit » Tue, Sep 02, 2025, 2:38 PM UTC

motorest wrote: post #351

felipeccastro wrote: post #262

Earlier quoted context omitted.

The train of thought is “what is everyone using? I’ll use that too”

> The train of thought is “what is everyone using? I’ll use that too” I'm not so sure about that. We're seeing Next.js being pushed as the successor of create-react-app even in react.dev[1], which as a premise is kind of stupid. There is something wrong definitely going on. [1] https://react.dev/learn/creating-a-react-app

You have to remember, Next is the only framework that can support some of the features in the latest version of React.

To many people, it's just basic logic: "everyone must want the latest React features, and the only way to get those is with Next, so everyone must want Next".

Re: Next.js is infuriating

#362

Post by mfrye0 » Tue, Sep 02, 2025, 2:39 PM UTC

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.

Re: Next.js is infuriating

#363

Post by hungryhobbit » Tue, Sep 02, 2025, 2:42 PM UTC

presentation wrote: post #184

bestest wrote: post #66

Earlier quoted context omitted.

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…

Sounds like you wouldn’t be a fan of React Server Components in general then since blending domains is its whole point.

Blending domains is great. Blending domains where you don't get logging at some levels because your framework is incompetent is not.

Re: Next.js is infuriating

#364

Post by conor- » Tue, Sep 02, 2025, 2:42 PM UTC

throwaway150 wrote: post #31

Rauchg wrote: post #5

Heard and appreciate the feedback. We’re well aware of the DX papercuts in Middleware. With 15.5 we made a big step in supporting Node runtime[1] which addresses a slew of issues people have reported over time. If I went back in time, I would have called it Routing Middleware or Routing Handler. A specific hook to intercept during the routing phase, which can be delivered to the CDN edge for specialized providers. It…

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?…

> Why can’t logger().info() just work in a sensible way?

I think OTEL is pretty sensible for a vendor-free and if you want to have a console logger you can use the console exporter[0] for debug mode during local development. Also if Next is designed as a framework to make it easy to build production-grade apps, having a standardized way to implement o11y with OTEL is a worthwhile tradeoff?

If you view that as being overkill, perhaps you're not the target audience of the framework

[0] https://opentelemetry.io/docs/languages/js/exporters/#consol...

Re: Next.js is infuriating

#365

Post by hn_acc_2 » Tue, Sep 02, 2025, 2:44 PM UTC

wetoastfood wrote: post #359

zelphirkalt wrote: post #283

Earlier quoted context omitted.

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.

It's the single file that is used to define the middleware function that runs. You can import whatever you want into it and decide how "you should combine [your middleware] into a single file."

I prefer this to having app.use / router.use scattered anywhere throughout the app init (i.e. Express)

Re: Next.js is infuriating

#366

Post by throwmeaway222 » Tue, Sep 02, 2025, 2:45 PM UTC

just log your rest services only, not your view. nextjs is a view. it's a half on the server, half not on the server thingy. it would never be consistent anyway.

makes more sense to go full CRA though. it's just a view

Re: Next.js is infuriating

#367

Post by [deleted] » Tue, Sep 02, 2025, 2:46 PM UTC

[deleted]

Re: Next.js is infuriating

#368

Post by noisy_boy » Tue, Sep 02, 2025, 2:48 PM UTC

DanielHB wrote: post #27

When I first saw Next.js I was immediatelly reminded of Meteor.js. I did invest a bit in learning into it and did some personal projects. But quickly realized it was both over-abstracted and inflexible which made it really hard to get it past prototypes. 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 Lar…

> 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/

Re: Next.js is infuriating

#369

Post by lubujackson » Tue, Sep 02, 2025, 2:48 PM UTC

motorest wrote: post #197

zero_shift wrote: post #134

Earlier quoted context omitted.

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

> 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 That is my opinion as well. Things like SSR are forced onto users with a very smooth onboarding, but I'm concerned that in practical terms this perceived smoothness can only persist if the likes of us pay the likes of Vercel for hosting our work. In some degree I f…

Looking at history, many popular frameworks have been "captured by a corporation" or in the case of React (FB) and .NET (MS), created by one. We mere SEs ride the wave of corporate whims, but everyone knows if and when they tighten the noose too hard everyone will move on to the next hot new thing.

Re: Next.js is infuriating

#370

Post by jakubmazanec » Tue, Sep 02, 2025, 2:49 PM UTC

hungryhobbit wrote: post #353

Demiurge wrote: post #337

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, ea…

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-incompati…

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?