←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 4 comments | 02 Sep 25 06:57 UTC | HN request time: 0.001s | source
Show context
YuukiRey ◴[02 Sep 25 10:04 UTC] 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 #
lysecret ◴[02 Sep 25 11:00 UTC] No.45101375[source]▶
What did you use instead?
replies(5): >>45101634 #>>45101964 #>>45102867 #>>45103386 #>>45110224 #
nonethewiser ◴[02 Sep 25 13:29 UTC] No.45102867[source]▶
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 for everyone.
replies(2): >>45104051 #>>45104121 #
tacker2000 ◴[02 Sep 25 15:10 UTC] No.45104121[source]▶
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.

replies(2): >>45104785 #>>45105368 #
1. fragmede ◴[02 Sep 25 15:56 UTC] No.45104785[source]▶
Sounds like a conspiracy theory. What's wrong with making the framework easier to use? Yes, the company that's paying for development on the framework is also paying those developers to make the golden path for deployment to use that company's PaaS offering, but unless we all band together and GoFundMe a framework that doesn't, how else do you want framework development to happen? Heroku/Cloudflare/AWS/GCp's entirely able to also pay those devs to make it easier to deploy to their platform.
replies(1): >>45104983 #
2. recursive ◴[02 Sep 25 16:09 UTC] No.45104983[source]▶
> What's wrong with making the framework easier to use?

Vendor lock in. Magic leaky abstractions are great until you need to debug something a few layers down when the magic stops working.

> how else do you want framework development to happen?

Loosely affiliated open source efforts maybe. If that doesn't work, I would prefer to have none at all.

replies(1): >>45105180 #
3. fragmede ◴[02 Sep 25 16:22 UTC] No.45105180[source]▶
> If that doesn't work, I would prefer to have none at all.

While we would all like to retire to a cabin in the woods and be a carpenter, and for corporations not to exist, that seems unrealistic.

Magic leaky abstractions are orthogonal to vendor-lock in, and the source is open, so I'm not seeing the lock-in part. The "hey it's easier and cheaper to smash the deploy-to-vercel"-in, sure, but things cost money. Either to a developer, or to a company.

replies(1): >>45108213 #
4. recursive ◴[02 Sep 25 19:56 UTC] No.45108213{3}[source]▶
I never claimed my preferences were realistic!

Stuff costs money, sure. But I don't think it's that simple. Next and Vercel come from the same organization. I have no objection to a paid hosting solution making it operationally simpler. However when that same org has control over the free thing, they can make it even more easier (probably grammatical! who knows) that it would have "naturally" been.