The reason people say this is because the scale of the problem is much, much worse in front-end javascript than in most other language communites and it's a real problem for people attempting to get to grips with best practice.
If your explanation was correct then we'd see the same problem everywhere at the same scale but there's something about front-end javascript that seems to exacerbate this issue.
I disagree that the scale of the problem is worse in the Frontend.
About being uncharitable: IMO this constant mischaracterization of frontend is the real uncharitable thing here.
I also do a lot of backend work and even the most "traditionally stable" programming languages (or frameworks) have a lot of churn in libraries, frameworks, patterns, toolchains, deployment methods and architectures. Which is "fine", that's how programming works!
But heck, I worked recently on a 8 year old Rails app that had four different methods/libraries/frameworks being used to wrap business code. But in the frontend that would be extremely rare.
If anything the frontend has been quite stable for the last 7 years or so when we settled on mostly React or Vue. The only real big change was Hooks, and even that was incremental and was an attempt to solve real problems in the ecosystem.
This is basically gaslighting. F/E churn is still wild. I’m staring at an article right now titled the top 14 react libraries you must try in 2020. That’s not a normal thing for a ten year old framework.
How is this gaslighting? Just because someone wrote an article to profit on your FOMO doesn't mean React (and also Vue) usage in the real world hasn't been extremely stable over the years. If anything, this kind of article is the one trying to fuck with your psyche.
You don't need any of the libraries in the article to make a good React app/website. Period. No, not even React-Router or Redux. And those two are probably the only ones that you'll see lots of companies/devs that actually ship stuff using. And both of them are not even that complicated, as is demonstrated in this article for the Router. Redux is also quite simple (hence why there's so many alternative implementations).
If anything the ones doing the gaslighting are the ones saying that we devs need to use ultra-complex build systems and gigantic libraries to make a "real app". It's the gaslighting of saying simple architectures "won't ever work" mixed with machismo of "real programmers do X".
Sure, if you want the complexity that comes with using those "must-use" libraries, feel free to have it. I won't say you're wrong by doing so. Maybe you REALLY need all 14 of them, although I doubt it. But please stop assuming that everyone is doing the same or has to. Nor try to deny the reality of me and lots of others getting things done without "14 must use libraries". Because that is the definition of gaslighting.
You seem to be conflating your personal experience here with everything happening around you which as you rightly point out is absolutely filled with this ever moving target that is absolutely impenetrable to beginners.
The React ecosystem looks like the crypto / nft space to outsiders. Nobody seems to agree on anything, no two projects look alike, it’s just this endless loop of people reinventing the same core bits over and over again for the past ten years.
I’m happy for you that this hasn’t been you experience but don’t tell me that the React ecosystem is stable. The reputation of the React ecosystem for many years has famously been that it’s a house of cards.
Nope. I'm not conflating my personal experience, because I'm not denying that other people can have different experiences. All I am saying is that blogs posts created to generate buzz and SEO-driven-traffic are not indicative of what the ecosystem really is, let alone of what an individual experience can be.
You, on the other hand seems to be claiming that the only reality that matters is the one that matches your own biases about an ecosystem that yourself seems to only participate from the periphery of SEO-spam blog posts.
It's funny that you're started by calling me a gaslighter when it is exactly what you're doing.
Claiming that React looks like Crypto/NFT only makes sense from anyone taking advice from such blogs.
The core bits have definitely not been reinvented, as the library itself hasn't really changed much to the outside in eight years other than the adoption of hooks and a few incremental advances.
Please spare the condescending "I’m happy for you" part. You're clearly not part of the industry that is using React in a stable way, and you don't seem to want to be part of. Even if your description of the React ecosystem were true, you're clearly on a personal vendetta here and has no intention to see anything change for the better.
> we'd see the same problem everywhere at the same scale
we do. Every C app implements its own linked list or hash table library. The entire Scheme community is nothing but toy interpreters of various stages of completeness (you can tell a project is serious when they implement call/cc). How many game engines do you think exist? It's a meme that game devs like to spend more time on their pet game engine than actually making their game. How many ORMs do you think exist for <language-of-choice>? At least half a dozen. At least. For any given language. Python, Ruby, Go[1]. ORMs, in particular, seem to get created over and over again. Probably because they are trivial to implement and allows one to voice their opinions on SQL abstraction (bike shedding).
The scale of the problem on FE is because if you want to work in the browser, you need to use JS. There's a diversity of engineers working on the FE and with them comes a diversity of ideas. People have different use cases in mind and build packages to satisfy those use cases.
There's nothing special about JS, but there is something special about being forced to use JS.
The reason people say this is because the scale of the problem is much, much worse in front-end javascript than in most other language communites and it's a real problem for people attempting to get to grips with best practice.
If your explanation was correct then we'd see the same problem everywhere at the same scale but there's something about front-end javascript that seems to exacerbate this issue.