Live data from Hacker News

Next.js is infuriating

blog.meca.sh

31–40 of 602 posts

Re: Next.js is infuriating

#31
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? This can't be such a hard problem, can it? Every other language and framework does it!

Re: Next.js is infuriating

#32
They're trying to do something that's fundamentally very hard. Unifying server-side and client-side code was always going to cause confusion when the difference becomes relevant.

Personally I'd rather go in the direction of having code that's explicitly server-side, explicitly client-side, or explicitly shared utilities. But you'd need more of a type-safe mentality to take that approach, and you'd probably scare off the majority who prefer runtime errors over build-time errors.

Re: Next.js is infuriating

#33
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.

Re: Next.js is infuriating

#34
post #14

Half these issues stem from a relative misunderstanding of exactly where the code is running. Next.js has layers upon layers upon layers due to the interplay between the browser, middleware, edge vs. node, SSR... It's an enormous amount of complexity and it really only fits under the following set of circumstances: * You sell a B2C product to a potentially global audience, so edge semantics actually help with latency…

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.

Re: Next.js is infuriating

#36
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…

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?

Re: Next.js is infuriating

#37
post #18
post #2

I don't get these kind of complaints, coming from Java and .NET web frameworks, Next,js is the only sane frontend framework followed by Angular. Saying this as someone doing Web related development since 1998, glory days of Perl and CGIs.

Angular is absolutely not a sane framework. I'd argue it used to be, but you can't build trust in anything after being rugpulled with 4+ major breaking refactors over the years. If you get it that wrong that many times, I start to wonder what the actual purpose of the framework is.

I kinda get what you are talking about (did those refactors too...), but which of major changes had such a high impact in your case?

Re: Next.js is infuriating

#39

Remix ( cough react router 7 framework mode cough ) is like the polar opposite of this, it's just a Request -> Response handler that you have to build your server around manually. Which I found kind of annoying at first but it does give you the freedom to do what you want.

I have been frustrated with Next.js changing it's API so much in the last few years and making things more and more complex and confusing. I am wondering about giving Remix a whirl for an upcoming forum/CMS rewrite with custom auth. Anybody else have experiences with Remix?

If you don't like changing APIs I'd stay away from the Remix guys. I know it is not like Next but I've used react-router, which had some API churn, later evolved to remix and then back to react-router... Backward incompatible changes are the signature of it. The documentation story is a problem too because of that. Completely different things are named the same and they are now building a new Remix, not even on React as far as I can tell.

Stick with a single version and you'd probably be happy though.

Re: Next.js is infuriating

#40
As much as I don't like most things about nextjs (I could write a vastly larger blogpost about it but won't as I like to keep my heartrate down), it feels like claude was trained specifically for it. In our experience, claude code is better at nextjs than other frameworks.
Post reply on HN