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

381–390 of 602 posts

Re: Next.js is infuriating

#381

Post by rimunroe »

palmfacehn wrote: post #17
selfmodruntime wrote: post #4

It really is. I am a staunch react defender, I work with it daily and I found the change from class components to hooks to be a better programming model. But whenever I work with Next, I feel like we lost the plot somewhere. I try a lot of frameworks and I like esoteric programming languages, but somehow Next.js, the frontier JavaScript framework embraced by React is the only experience where half the time, I have no…

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".…

> Others will disagree, but personally I prefer to minimize my exposure to JS by decorating traditional HTML+CSS documents with vanilla JS as needed.

If you don't mind my asking, what sort of applications have you worked on, how many contributors were there, how long was their lifespan, and how long did you work on them for? Personally, I've found the type of "vanilla" JS approach to be prohibitively difficult to scale. I've nearly exclusively worked on highly interactive SaaS apps. Using a substantial amount of JS to stitch together interactions or apply updates from the server has been unavoidable.

The engineering organizations at companies I've worked at have ranged in size from three devs to over 20,000. Projects I've worked on have ranged from three devs to maybe 500-1,000 (it's sometimes hard for me to keep track at a giant company). I've worked on projects using "vanilla" JS, Knockout, Backbone, Vue, and React[0]. The order in which I listed those technologies is also roughly how quickly the code became hard to maintain.

[0] This is not an exhaustive list of which frontend frameworks/libraries I've used, but it's the ones I have enough experience with to feel comfortable speaking of the long term support of[1]. For example, I used Ember heavily for about a year, but that year was split between two projects I spent six months each on. Similarly, I've used Next.js, but only for prototyping a few times and never deployed with it to anything other than a private server.

[1] Except Lightning Web Components, which I've used a lot but hate so much that I don't want to dishonor those other technologies by listing it alongside them.

Re: Next.js is infuriating

#382

Post by lacoolj »

lol when i try to explain this to fellow devs in discords they adamantly fight me on it and i dont even bother getting further into it.

When I see Next.js on a job posting as a "requirement" or even as a "something we use" I immediately discard it

Re: Next.js is infuriating

#383

Post by zallarak »

Agreed. I've run into so many issues with documentation and sane defaults, and the Vercel team response is to always gaslight you into thinking you've done something wrong.

The truth is, its just poorly designed software.

Where it shines is batteries included for getting started. They realized if you have low activation energy requirements, you will win a critical mass of people who put up with your crap. A good metaphor for devtools overall.

Re: Next.js is infuriating

#384

Post by dminik »

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…

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).

Re: Next.js is infuriating

#385

Post by tacker2000 »

nonethewiser wrote: post #288
lysecret wrote: post #133

Earlier quoted context omitted.

What did you use instead?

People will complain about Next but there is no perfect solution. The complexity driving the problems with Next materialize in other forms elsewhere. Remix is a competitive option with its own quirks. You can always roll your own with Vite, Tanstack router, etc. but then of course you're manually implementing the same stuff albeit better suited to your needs. Which isn't necessarily bad but it's not the right choice…

The perfect solution is to use React for the frontend (where its main purpose and strengths lie) and use something like PHP, Java, ruby or whatever for the backend.

This insanity of server side react introduces all kinds of unnecessary quirks.

Also, the VC-funded Vercel is of course purposely dumbing down Next.js, so that everyone pays them. Its a trap everyone should be aware of.

Re: Next.js is infuriating

#386

Post by [deleted] »

Kye wrote: post #305
a2tech wrote: post #256

Earlier quoted context omitted.

Working with a client just last month that hired an African engineering group to build a tool for them. What they got delivered was a Next.js train wreck that was so coupled to Vercel's hosting that I couldn't make it run successfully anywhere else. The customer was a non-profit and didn't want to/couldn't afford Vercel's hosting so asked if I could try and make it run and I (naively) thought 'its just javascript, it…

I haven't heard anything about trends, stereotypes, positives, and negatives regarding IT and development in Africa. Following HN's guideline to increase curiosity as topics get more divisive (as this subthread has), and looking for "the strongest plausible interpretation of what someone says" I'm going to assume the best: What's the story here? I assume this group was chosen for a reason and didn't meet expectations…

[deleted]

Re: Next.js is infuriating

#387

Post by ohdeargodno »

arcfour wrote: post #334
ohdeargodno wrote: post #145

Earlier quoted context omitted.

Windows has had envvars since before Linux existed. It also has FindFirstChangeNotification (or ReadDirectoryChangesW if you hate yourself) since before inotify existed, etc. Windows has pretty much everything you can dream of (although sometimes in the form of complete abominations), it's just that the people employed by Vercel don't give a shit about using native APIs well, and will map everything towards a UNIX-is…

This seems to ignore the possibility of Windows having done them in a UNIX-ish way to begin with, which would be infinitely better than what Microsoft came up with.

Windows had most of these APIs _before_ UNIX ever dreamed them up. You can jerk yourself off about the superiority of io_uring all day long, but it had been in Win32 for 15 years prior, and has kept compatibility throughout. I can't promise that io_uring will still be in the kernel by 2040.

So, yeah, speaking in hindsight is really easy.

PS: no, the UNIX way is also shit, just in a different way.

Re: Next.js is infuriating

#388

Post by zero_shift »

emn13 wrote: post #252
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

The author's examples of rough edges are however no better when hosted on vercel. The architecture seems... overly clever, leading to all kinds of issues. I'm sure commercial incentives would lead issues that affect paying (hosted) customers to have better resolutions than those self-hosting, but that's not enough to explain this level of pain, especially not in issues that would affect paying customers just as much.

I agree, but I suspect the cleverness is part proprietary behaviour, part having a monstrosity that only runs as intended on their own infra

Re: Next.js is infuriating

#389

Post by zero_shift »

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…

Might have? The official React docs recommend Next.

That capture happened... two years ago? (Perhaps there's a good blog post there, if it doesn't exist already)

Re: Next.js is infuriating

#390

Post by wmanley »

recursivedoubts wrote: post #290
komali2 wrote: post #85

Earlier quoted context omitted.

In my opinion (9 years FE exp) you should build your ecommerce site in shopify or wordpress + woocommerce or some other off the shelf tool. It will be up before the evening's out and you won't be spending that much extra than you would have anyway, and everything will Just Work (tm) and look pretty good (chuck out 50$ for a nice wordpress theme and you're golden). If you insist on rolling your own, Django + templates…

htmx will not have gone through 2 breaking change upgrades https://htmx.org/essays/future/

And also:

> and so have 4 different libraries they rely on

HTMX has no dependencies. https://htmx.org/essays/vendoring/

> and actually the most up to date version of two libraries you rely on are not interoperable right now because they depend on different node versions

HTMX has no build step. https://htmx.org/essays/no-build-step/

Post reply on HN