←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 1 comments | | HN request time: 0.204s | source
Show context
YuukiRey ◴[] No.45101009[source]
I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else.

In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts.

Next.js is easily the worst technology I've ever used.

replies(16): >>45101028 #>>45101139 #>>45101375 #>>45101378 #>>45102069 #>>45102103 #>>45102427 #>>45102810 #>>45102903 #>>45103225 #>>45104004 #>>45104045 #>>45105250 #>>45110734 #>>45112201 #>>45126685 #
throwaway77385 ◴[] No.45102903[source]
I'm so glad I'm not the only one thinking this. I built a medium-complexity, money-making, production-grade app in Next.js and started out on Vercel's hosting (and Google Firebase) and then moved to hosting myself and stripping out Firebase, replacing it with Pocketbase.

Pocketbase was the ONLY good thing about this journey. Everything else sucked just so terribly.

Infinite complexity everywhere, breaking changes CONSTANTLY, impenetrable documentation everywhere.

It is just so, so awful. If we rewound the last five years of FE trends and instead focused on teaching the stuff that existed at the time properly, we'd be in a much better position.

I've also built a very complex React frontend (few thousand users, pretty heavy visual computation required in many places). And while I don't particularly like React either, Next.js was even worse.

And lastly, built a CMS in Go, with vanilla JS. And while the DX sometimes feels lacking, I just can't help but feel that I actually know wtf is going to happen when I do something. Why is that so hard?

In React and Next.js I am STILL, AFTER SIX YEARS constantly guessing what might happen. Yes, I can fix just about anything these frameworks throw at me, thanks to all the experience I've gathered about their quirks, but it all just feels to messy and badly designed.

In Go, the last time I guessed what might happen was in the first six months of learning it. No surprises since. Codebases from years ago are still rock-solid.

Why can't we do this at the frontend, goddammit?

replies(3): >>45103089 #>>45103528 #>>45103671 #
fourseventy ◴[] No.45103671[source]
" Codebases from years ago are still rock-solid." This is the biggest thing for me. I recently pulled down an 8 year old hobby Java/Maven project I had and it compiled and ran perfectly on the first try. Imagine trying to get an 8 year old javascript project to work...
replies(5): >>45105063 #>>45105524 #>>45109353 #>>45111005 #>>45114167 #
elbrian ◴[] No.45111005[source]
You mean like this?

nvm use && npm i && npm run dev

replies(4): >>45112206 #>>45112607 #>>45112708 #>>45112716 #
1. Aeolun ◴[] No.45112206[source]
Does NPM work for you in the first place? Much less after 5 years? They’ll have gone through 2 major revisions on their lock file format, and it’ll complain you don’t have the exact version of node specified in your package.json