Humans have been using physical and mental systems to manage complexity for eons, I simply can't understand this argument. React doesn't automatically fix spaghetti code if you don't know how to organize a platform-sized code base efficiently in the first place.
This is like saying "cabinets don't help organize a kitchen if you don't put anything in them" -- I mean, duh, you have to use it right. That's not an argument to have no cabinets.
There's a reason nearly ALL major web applications rely on a _framework_....rails, django, laravel, you name it. These exist because it's really hard to organize vanilla code without a framework. React and FE JS are no different.
If you're arguing against using a FE framework to organize FE code, you're basically saying "We don't need frameworks in general! All code should be inherently organized!" That's not realistic. It's just not feasible when you have a large project.
> This is like saying "cabinets don't help organize a kitchen if you don't put anything in them" -- I mean, duh, you have to use it right. That's not an argument to have no cabinets.
Good counterpoint.
Parent comment sound too much like the "TRUE programmers don't use data structures" old meme
Yeesh, you've badly misinterpreted my comment. Re-reading it, I'm partly to blame here.
>That's not an argument to have no cabinets.
This isn't the point I was trying to make. I didn't mean to piggy back on this part of the parent comment: "Have you worked on a platform that uses nothing but pure JS and fetch calls?"
I meant to respond to this part of the parent: "they are tools for developers to streamline development and make maintenance easier." I often find that the most ardent React fans will see "not React" and jump immediately to "spaghetti of vanilla js and fetch calls," with no further questions asked.
I'm trying to argue against React dogmatism, I'm not arguing in favor of "no framework" dogmatism.
Well, if we take a step back from React and talk about a sort of data-first approach to UIs, I think they are definitely, much easier than the old jQuery era.
Mutable state, notably knowing all possible variations of said mutable state and how it relates to everything, is very difficult imo.
Is React the best implementation of this? Definitely not. It will evolve as time goes on. But I don't think I could ever manage state in the jQuery mutate-everything model again.
To be clear I'm not advocating for React on every possible use case. In fact I've grown weary of it over the years, but not for the reasons the comment I was responding to pointed out. My point is that React makes the process of organizing frontend code easier, not that it's the only way to do so.