7 ms·
Unclear why React has to service that need. jQuery still exists, is still supported and maintained, and serves that need much more effectively I wager. And tak
by diffrinse 6y ago
Unclear why React has to service that need. jQuery still exists, is still supported and maintained, and serves that need much more effectively I wager.
And taking a step back I think many people in frontend confuse React for a jQuery alternative, the thing you whip up a web project with by default, but it really isn't. That there is a component ecosystem might suggest its a jQuery alternative, but they really are for different scales of application programming.
I think it's this idea most harmful about React adoption and to be fair React marketing hasn't exactly said otherwise. So we get web pages with massive JS deps cause most people are probably using React for a productive developer experience rather than a fitting use case that actually justifies resorting to a virtual DOM model for applying view state, and yet React sold itself on "we probably know better than you about efficient DOM updates". That's true if you have lots of Juniors hanging around.
- hajile 6y agoI think that depends on how you use react. When I first started using it to replace jQuery, it resulted in different use patterns than when making a greenfield SPA. I just wanted something easier to maintain and it did that in spades. React was an easy drop-in replacement. No state library or whatever else (there weren't a ton of libraries at that time). Just add React CDN, code up some simple components and add them to the page (they'd get a list of elements with the correct classname and inject one copy for each element). Today, I still take a similar approach for the occasional CRUD site I work with. The only change is that now I use the much smaller pReact and use functional components with hooks instead of the old React.createClass() from the early days.