Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js is infuriating

blog.meca.sh

Post reply on HN
Print view View original

471–480 of 602 posts

Re: Next.js is infuriating

#471

Post by dizlexic »

ale wrote: post #162
celicoo wrote: post #157

Reading through all these comments gives me hope. Finally people are speaking up about what we have all been experiencing in isolation — the gradual enshittification of Vercel/Next.js in service of Vercel's business model. The middleware issues the OP describes are not bugs, they are symptoms. When you can't get basic logging to work, when you can't use WebSockets, when you are forced to deploy on edge runtimes that…

To be fair Next.js is just following the natural progression of what their product always has been: holding devs' hands in all things deployment at the expense of vendor lock-in. Being aware of Vercel's limitations is not about the open web, it just means you should be setting up servers yourself at this point.

This

I was talking to a fellow dev at the company I work at and he was extolling the virtues of one-click nextjs deployments. As the conversation progressed it turned out he'd never actually had to set up or manage his own servers and felt that it was a waste of time for him to learn.

It hurt my soul. I am considering linking this article, but i feel it may come across as aggressive.

Re: Next.js is infuriating

#472

Post by pjmlp »

Etheryte wrote: post #440
pjmlp wrote: post #418

Earlier quoted context omitted.

Wrong again. Spring Boot doesn't provide a serious production quality deployment without configuration. Bare bones logging into standard out, yes. That isn't production quality . Production quality is telemetry logging, log rotation and zipping, forwarding logs to Kibana or Datadog dashboard.

This is a silly no true scotsman argument. First you don't say what you mean and then stick up your nose when no one has any idea what you're on about. Anyone is capable of making up an arbitrary set of requirements that no language nor framework fulfills. This doesn't change the fact that for most languages and frameworks, logging is a boring, solved problem. That Next.js doesn't bring that to the table is more than…

Nope my dear, you're the one insinuating that logging works out of the box in production quality deployment without any kind of additional configuration or code changes, hence please make use happy, where that is the case.

Word vomit into standard output isn't production quality.

Re: Next.js is infuriating

#474

Post by webdevladder »

smaudet wrote: post #196
webdevladder wrote: post #174

Earlier quoted context omitted.

Full-stack rich schemas, not the poor lossy JSON Schema or other language-agnostic ones, are so nice for long-term quality and development velocity. You get to categorically avoid bugs that drag teams down. Zod 4, ArkType, and Valibot are all great.

This is the problem inherent in web dev I suspect. JS developers thought they reached the zenith of programming because they had a type system and could realize some gains via strong typing checks applied to what would otherwise be network calls. However, at a certain point, you're better off not writing a web app anymore, just an app with a somewhat wonky, imprecise runtime, one that lacks any sort of speed and has…

You've missed the point, it's inherent in any serialized communication, and the gains are far greater than a type system. Protobuf and friends, and every type system in existence, pale in comparison to runtime capabilities and guarantees.

Re: Next.js is infuriating

#475

Post by conradkay »

Etheryte wrote: post #41
arend321 wrote: post #22

Earlier quoted context omitted.

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

And the reason they're all in on streaming to begin with is because they're sending massive amounts of data back and forth all the time. Like Sean Goedecke said in his API design writeup [0], a technically poor product can make it nearly impossible to build an elegant API. I believe we're seeing the same thing with Next.js, all of these wonky interfaces derive from the underlying architectural issues. [0] https://www…

Maybe it's a good design from the perspective of making more money from your hosting business

Re: Next.js is infuriating

#476

Post by keeganpoppen »

Lucasoato wrote: post #158

> we of course have no idea what actually happened since the default logging is only enabled during development Wait, if you have issues with logging, why don’t you set up opentelemetry? It’s really easy to add into a project [1], and if you don’t want to manage it, you can easily find some cost efficient solutions like Grafana Labs [2]. [1]: https://nextjs.org/docs/app/guides/open-telemetry [2]: https://grafana.com/

this is a fantastic, state of the art way of “now we have two problems”, i can say unequivocally from my own experience.

Re: Next.js is infuriating

#477

Post by koonsolo »

fragmede wrote: post #452
koonsolo wrote: post #448

Earlier quoted context omitted.

Then why did HTML became so popular if win32 or MFC were so great?

Because it solved different problems. CSS is terrible, but deployment simplicity and distribution channel were more powerful than how shitty HTML is for making GUIs. The fact that MFC was owned by Microsoft didn't help either.

Why would you make GUI's with HTML? Its main use was for content, not applications. Hyper Text Markup Language.

So you agree both solve different problems. Well, those are 2 use cases of front-end right now.

Re: Next.js is infuriating

#478

Post by lysecret »

lmm wrote: post #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…

Fully agree really enjoying TRPc for this.

Re: Next.js is infuriating

#479

Post by coronapl »

That’s the paradox of Next.js: it can feel extremely simple and extremely complex at the same time. For a small hobby project hosted on Vercel, I’d recommend it. For building a full SaaS product, I often regret it.

I’ve run into this myself. I tried middleware, AsyncLocalStorage, even wrapping layouts and pages in HOCs. After plenty of research, it still feels over-engineered for such a trivial task. Ironically, my understanding is that Next.js on Vercel already provides a requestId by default.

Another recurring issue is the documentation. The moment you hit anything even slightly advanced, it becomes too simplified to be useful, and the only guidance you find is a handful of open GitHub issues.

Re: Next.js is infuriating

#480

Post by 1oooqooq »

fragmede wrote: post #406
ncphillips wrote: post #132

Earlier quoted context omitted.

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

> 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. In what way has that been a boon? Context switching between languages, especially PHP, seems like an even bigger headache. Is it strlen($var) or var.length or mb_strlen($var)? Do you ever output JavaScript from PHP? My biggest question though is how do you avoid ever duplicating logic between js…

spoken like a middle manager.

why would anyone send JavaScript from the php? why care about duplicating a couple json translations and null checks... it's all code is today anyway.

and switching languages? you can't use most of js as it is. even something as simple as split() have so many weird bugs that everyone just code from a utils lib anyway.

Post reply on HN