Next.js is infuriating | slacker news

Similar to Meteor.js, they've tried to abstract things that aren't really abstractable (is this even a word?).

It handles edge-cases extremely poorly, and when you have those scenarios, you either need to find a workaround (so code becomes ugly and painful to maintain) or give up.

I've worked with it for a project, gladly never again.

I'll extend my feedback about Node.JS backend. Look how many flavors: deno, bun... It's a mess.

Node.js a terrible platform for server-side in comparison to Java/C#(performance/stability) & Ruby/Python(dev speed).

The only reason it is successful is that everybody knows JS/TS. But just because everybody knows it is rarely a reason to use it.

The event loop is quite nice and easy to reason about, but that's all there's to it. It is single-threaded and comes with gotchas, with at the end being in my opinion a negative aspect of it.

Many other langs/platforms offer also an event loop for concurrency, but they aren't often used. In the end no matter how much we hate threads, they serve a great purpose that has been battle-tested for so many decades.

Unfortunately companies adopt programming languages based on hype and trends, rather than technical reasons.

Until when we will have people hyped up about writing web servers in CSS, even though it doesn't make any sense to?

TLDR: It isn't only Next.JS, but the whole NodeJS thing isn't that great.

>is this even a word

Everything can be a word if you know what you're trying to say. Don't let anyone tell you otherwise. If they try, say: фakdelengiчpolis!

Even though I'm a fan of looking for underlying motivations to what people do, I'd be wary of pointing out "only" reasons for anything. I know it's a rhetorical exaggeration, but still.

For example, I've found Node to do what Python does, only better. For example, Node does dependency resolution without involving the OS package manager. And ultimately, people end up using whatever they become comfortable with.

Which is not an exact science and people resist it being made into one. (Maybe if it was, it'd be much easier to sell people on working with the "least worst" tooling that is not actually good for anything.)

But the important thing is that on the backend they're all different. The baseline is the CPU, and you get to choose between real tools with real histories of real tradeoffs. Even if the tradeoff is "run JS" or "be written in C++" or smth else.

On the frontend, the baseline is JS, and whatever the browsers bolt to JS, and as us few sane keep pointing out, JS land is already such an "OS-within-an-OS" that there is very little point to building entire freaking frameworks between that and the application, just for the sake of having to swim through someone else's moat instead of invoking the APIs directly (which are also better designed for the most part).

So, in order to differentiate the market, one would need to build at least 1 "layer of layers" on top of JS, some products in which are gonna more pointless, while others are gonna be less pointless (all of this to all different people of course). That way the user gets to choose between what sucks more vs what sucks less, and one gets to feed on the attention paid to the choice of lesser evil; or -- if insufficient attention is paid -- to entirely direct the choice in whatever direction. It's a win-win.