Next.js is infuriating

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.

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 for everyone.

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.

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.

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

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