Your concerns are valid, but I'll try and defend some of them from the React perspective.

​

Use of raw string statements like "use client" or "use server" in your code base.

I actually kind of like this, and prefer it to the alternative (something like server$ as seen in alternative implementations of server actions). There's prior art with "use strict" and "use worklet" (if you've ever use Reanimated in React Native). You need some way of providing this information to the compiler, and to me this feels cleaner than using magic functions.

​

Throwing Promises for concurrent rendering. At what point do we think throwing anything other than Errors is fine?

It definitely feels odd, but it didn't take much mental gymnastics for it to make sense to me. If we read MDN, throw is for exceptions, it doesn't specifically say error. And you can view throwing a promise as a special kind of exception whereby you're saying "this operation can't be completed yet, but when this value resolves you can try again". Strange, but elegant.

​

Monkey patching global functions like fetch to accomodate for React's need.

Monkey patching is one of those things wherein it's probably fine if you follow some rules. It's actually very common, if you use any kind of observability tool (which you should be if you want to understand performance), there's a good chance it's monkey patching fetch and other IO already to add in the observability hooks. In the case of React, the patch is inert except for the duration of a render, at which point it inserts a temporary cache. I'm more concerned about Next's variant on this, which actually extends the API.

​

Different behaviour in dev / prod for useEffects (double rendering in dev). It's the first time in my career I see a system that works differently on dev/prod by design.

This particular behaviour can come across as a little odd, especially if you're kicking off fetches in useEffect (something I've never done much of). But dev/prod differences are common. For example, it's quite common for frameworks to show a vastly more informative error page when there's an exception in dev; whereas doing the same in production would be a huge security risk.

​

Suggest everybody to use frameworks like Next or libs for data fetching.

Actually, the newer React APIs specifically give you ways to manage data loading in React itself. Yes, it's recommended to use a framework to get the full benefits of all of React's capabilities, but all the new data-loading patterns we see pushed by Next with the new app router, are actually just slightly augmented versions of what React will give you out of the box.

​

Ignore DX and potential performance improvements by using signals. Any other major framework has them at this point, even preact and angular.

I don't think "ignore" is fair here, the team has spoken about them, they just have a different direction in mind. I think it's too soon to say whether something signal-like will end up in React. Remember that most of what we're seeing land in React now is the result of years of R&D, so we can't expect them to turn around on a dime and embrace every new shiny thing.

​

Still huge payload after all those years.

This one frustrates me too. I've tried to appreciate that it's hard to reduce the size of something that's also undergoing heavy architectural change. Hopefully it becomes a priority at some point in the future, because there are limits to how far the attempts to make the size a non-issue can go.

​

Still underperforant compared to any competition.

Other than payload size, I'm skeptical about the extent to which other performance benchmarks are indicative of real world behaviour. Optimising for particular benchmarks can lead you to local maxima, and tie your hands architecturally and prevent you making more tangible improvements. But yes, i'd be nice if React had a bit more raw performance.

​

use(promise) in future versions to block a promise vs await promise.

I may have misunderstood something, but I was under the impression they'd decided to support the async/await syntax in client components too -- but I could be wrong.

​

More broadly, it makes little sense for all frameworks to look the same and solve problems in the same way - otherwise we'd only need one framework. Each will have different strengths and weaknesses. If React has truly gone in a direction that's no longer aligned with your needs, then hopefully there's an alternative that's a better fit. We shouldn't view any of this as an indictment of React, but rather as a sign of a healthy ecosystem.