> has a lot of people working with it who have very little CS background
This and so much this. This applies to "frontend development" in general. I work as a contractor in the frontend space (Europe, no where near FAANG like companies) and very often I meet other "devs" that have basically become frontend "engineers" out of being a webdesigner - like you know, creating nice html templates for wordpress, having decent CSS and photoshop skills and later in their career started to copy-paste some jquery plugins into their template to get nice animated toggles and alike. It is very common in "frontend teams" that people started to get into JS out of webdesign, and have never actually programmed in any other language.Another issue is even with people with a CS or another STEM background, they only get taught in the "traditional" OOP sphere on top of blocking thread environments. Those usually have a hard time wrapping their heads around higher order functions or async-based development (and to be fair, I also had a hard time when I first encountered it).
I don't disagree, but my follow-up question with that statement is "ok, now what?"
If you've got a weak/inexperienced developer who's stuck in a framework where they have have to start grokking async/HOF/whatever to solve the problem they've encountered, where do they go from there? It's fine and good to blame the framework they're operating in to be shitty, but they a) didn't have the skills initially to make a solid decision about the framework to use, and b) are now likely stuck with it (unless they're going to do a rewrite with something else).
Early cars were hard to learn, drive, and maintain. Over time they got better via trial and error by manufacturers. The desktop IDE's of the early 90's were like this, but got better over time (until web ruined their market). However, the web is still stuck in 1903: simple things are esoteric. Perhaps because too many other things about "cars" keep changing? Something is wrong. CRUD web dev is a mess.
To my mind they are oftentimes magic pixie dust that can turn a hideous, verbose and inflexible API into something humane and readable.
If you bring up a scenario, I can probably poke holes in it. Done it many times in many debates. I don't mean to sound arrogant, but I keep winning THIS one for whatever reason.
Whatever the case, just because we wish solutions to those problems were easier to understand doesn't mean reality owes us that. I suspect React in particular, being in the web dev space, has a lot of people working with it who have very little CS background. Because they don't understand how React works under the hood or even above the hood is "something wrong with React"? I'm not sure I buy it.
I've seen a lot of really poor React code that breaks all kinds of best practices, many of them explicitly laid out in the docs. Even before hooks came along. In fact it's been hard to find examples of people who understand the dom well, much less React. I will continue to suspect there's something wrong with most of the people using React, not React itself, which from my perspective has only become better over time.