Next.js is infuriating

Thanks for the note! Indeed, it is also challenging when experience hides what things are not obvious or necessary to make further connections when reading the docs. It is an area of continuous improvement.

> The documentation is written to be easy and friendly to newcomers, but is really missing the details and nuances of whatever execution context a given api is in and does not touch on derived complexities of using react in a server environment etc.

I think on this particular topic, there had been an assumption made on the docs side, that, listing Edge runtime (when middleware was introduced), as its own thing, that might as well run in another computer, would also communicate that it does not share the same global environment as the underlying rendering server.

I'll do some updates to narrow this down again.

> The documentation mostly tells you what exists, but not how to use them, how they get executed, common pitfalls and gotchas etc etc.

Do you have anymore examples on this. I have been improving the revalidateTags/ Paths, layouts, fetch, hooks like useSearchParams, gotchas with Response.next, etc..

I know the OP post does talk about issues not being responded to, but that trend has been changing. If you do find/remember something as you describe, please do open a documentation issue, pointing to the docs page and the confusion/gotcha - we have been addressing these over the past months.

(My username has never been more appropriate!)

Fact is the only way around this in the frontend without a monolitic "batteries-included" all-encompassing all-knowing all-mighty framework is through standardization which can only be pushed by the browsers. Like if browsers themselves decided how bundlers should work and not have them be extensible.

And this tooling-hell is not only a browser frontend problem only either, it is also quite common in game development. Where you also have these monstrosities like Unreal Engine that "includes batteries" but makes it really hard to troubleshoot problems because it is so massively big and complex. A game engine is basically a bundler too that combines assets and code into a runnable system to be run on top of a platform.

The middleware issues the OP describes are not bugs, they are symptoms. When you can't get basic logging to work, when you can't use WebSockets, when you are forced to deploy on edge runtimes that don't support Node.js APIs — these are all deliberate choices to push you toward Vercel's platform. Guillermo and his team have prioritized their cap table over the open web.

This is why I started https://github.com/openuiai/next.js last month. The web is humanity's greatest collaborative achievement. We are building toward a global, decentralized network that should enable unrestricted computation and storage for everyone. And for that to actually happen, we need frameworks with the power and flexibility that Next.js used to have. But instead we are all watching Vercel carve it up to lock developers into their platform

Next.js used to be great. Now it's a trojan horse for vendor lock-in. The fact that so many developers are comparing it to SharePoint and Lotus Notes should be a wake-up call.

To everyone frustrated: you are not wrong. The framework is ACTIVELY working against you unless you are on Vercel.

I'm working on OpenNext.js every single day — still climbing the learning curve of the massive spaghetti codebase, but fully committed. We are already running OpenUI on a fork with full Node.js middleware support and native WebSockets. These will merge into OpenNext.js once I have properly cleaned out the cruft (their CI/CD alone has cost me $400 just figuring out how to untangle it). But I'm taking the time to do this right.

Guillermo: Vercel/Next.js shouldn't dictate where we can deploy. It should respect the open nature of the web. You know this, but you chose the money instead.

If I had to create something that has a UI I'd just go with a bog standard server rendered multi page app, built using really boring technology as well. If you like Javascript and friends, go with Express. Nowadays you can run Typescript files directly and the built-in test runner is quite capable.

If a single page application makes sense, then go with vanilla React. For a highly interactive application that's potentially behind a log in anyway, you probably don't need React Server Components.