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.

▲

tacker2000 5 days ago | parent | next [-]

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.

▲

nonethewiser 5 days ago | parent | next [-]

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

Im kind of confused by what you mean here. You can use PHP, Java, Ruby, etc. for the backend with Next.js. You can even use if for the SSR server if you want.

I guess you are actually talking about simply not doing server side rendering at all? Im just clarifying because I think that still constitutes using "React for the frontend." I mean, how could React be used for anything BUT the frontend?

The server side rendering is actually one of the objective goods Next.js offers (not necessarily that it handles the complexity of it well). I mean, if you dont need that, sure... that's one more reason to just use Vite. But the backend choice is irrelevant.

▲

fragmede 5 days ago | parent | prev [-]

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.

▲

recursive 5 days ago | parent [-]

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

▲

fragmede 5 days ago | parent [-]

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

	▲	recursive 5 days ago \| parent [-]
		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.

▲

claytongulick 5 days ago | parent | prev [-]

Lightweight native web components rendered on the light dom with lit-html and a simple API layer in express 5 is about as close to perfect as I've ever found.

The only "weakness" is that it doesn't have guard rails, so may not be great for larger teams with mixed experience.