3 ms·
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 wa
by Benjammer 6y ago
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.
- Kaze404 6y agoTo 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.
- asdkhadsj 6y agoWell, 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.