4 ms·

How is developing with react quicker than jQuery for most websites? React never made development faster.. easier to manage complex state but not faster develop

by ipaddr 4y ago

How is developing with react quicker than jQuery for most websites? React never made development faster.. easier to manage complex state but not faster development.

deleted 4y ago
[deleted]
rektide 4y ago
With jQuery you are working with existing state & ongoingly trying to update it. In some cases you just need to turn on and off a class, but once you start making significant modifications, things get complex. Oops, you just replaced some DOM with some other DOM that's mostly the same, but now all your event handlers are lost- so now you've got to go add yet more band-aids to re-build event handlers. There's constant inter-dependencies when you try to keep working with one piece of state. React hides all that away. The virtual-dom just works. Event handlers all get faithfully reconnected. You never end up accidentally having multiple copies of content or having deleted too much content. As opposed to the DOM's native retained mode rendering, React gives a much simpler immediate mode rendering. And it's often faster. It's easy to do too much work, to end up replacing more than you need to when you are hand-working the DOM. React's diffing algorithm is quite effective at doing just what updates actually needed be done, where-as before I as tech lead would have to go re-walk through my teammates code & tune & optimize it, fix some of the gross inefficiencies. Working the DOM used to be a complex & subtle art. A lot of simple stuff you could just do & it was ok. The API was never delightful, even with jQuery. But there was so much latent knowledge, so many particulars, so many hazards. It, in my view, made even simple things much faster to develop.
- ipaddr 4y ago
  If your website isn't managing complex state then jQuery will be quicker and easier. If you are making hundreds of dom changes react will be quicker.. but the average website isn't doing this. There should be complexity minimum reached before react can be used.
  - rektide 4y ago
    This is a gross over-simplification of a much harder decision to make. It depends. State can be simple & small, but it can still be hard to update your page accurately & quickly without tripping on side effects. For some tasks, this isn't a risk. For others, it's a headache. There is no hard fast & easy rule to tell how problematic managing the DOM yourself will be. It's not about state size. It's about how much work you're going to have to do to maintain the dom, & the risk of one interaction jamming up something else. Knowing you can safely work the dom requires a blend of careful analysis & general intuition, to feel out where different concerns might collide, and you can be wrong. And adding just one more feature down the road can cause significant nightmares, blow up these assumptions. For someone else who comes along to do some work & who doesn't understand every assumption you've made about interactions, the risk compounds. Moving from a retained mode DOM-manipulating view of the page to a immediate mode v-dom backed view such as react can save a huge amount of trouble. That just deciding & justifying your decision that only a small tool is required is complex that I'm more in favor of using React everywhere than I was before you posted: this oversimplification & overreduction emphasizes to me how particular & careful you have to be about justifying picking a less-safe tool. Simply tallying up the state you need is far beside the point. The DOM's risk has always been more about compound interactions. If you have completely isolated things on the page that only need a couple fixed features, and you never plan to grow the capabilities, maybe conventional DOM swizzling is ok. I still find it hard to recommend.

by ipaddr 4y ago

How is developing with react quicker than jQuery for most websites? React never made development faster.. easier to manage complex state but not faster development.

deleted 4y ago

[deleted]

rektide 4y ago

With jQuery you are working with existing state & ongoingly trying to update it. In some cases you just need to turn on and off a class, but once you start making significant modifications, things get complex. Oops, you just replaced some DOM with some other DOM that's mostly the same, but now all your event handlers are lost- so now you've got to go add yet more band-aids to re-build event handlers. There's constant inter-dependencies when you try to keep working with one piece of state. React hides all that away. The virtual-dom just works. Event handlers all get faithfully reconnected. You never end up accidentally having multiple copies of content or having deleted too much content. As opposed to the DOM's native retained mode rendering, React gives a much simpler immediate mode rendering. And it's often faster. It's easy to do too much work, to end up replacing more than you need to when you are hand-working the DOM. React's diffing algorithm is quite effective at doing just what updates actually needed be done, where-as before I as tech lead would have to go re-walk through my teammates code & tune & optimize it, fix some of the gross inefficiencies. Working the DOM used to be a complex & subtle art. A lot of simple stuff you could just do & it was ok. The API was never delightful, even with jQuery. But there was so much latent knowledge, so many particulars, so many hazards. It, in my view, made even simple things much faster to develop.

ipaddr 4y ago
If your website isn't managing complex state then jQuery will be quicker and easier. If you are making hundreds of dom changes react will be quicker.. but the average website isn't doing this. There should be complexity minimum reached before react can be used.
- rektide 4y ago
  This is a gross over-simplification of a much harder decision to make. It depends. State can be simple & small, but it can still be hard to update your page accurately & quickly without tripping on side effects. For some tasks, this isn't a risk. For others, it's a headache. There is no hard fast & easy rule to tell how problematic managing the DOM yourself will be. It's not about state size. It's about how much work you're going to have to do to maintain the dom, & the risk of one interaction jamming up something else. Knowing you can safely work the dom requires a blend of careful analysis & general intuition, to feel out where different concerns might collide, and you can be wrong. And adding just one more feature down the road can cause significant nightmares, blow up these assumptions. For someone else who comes along to do some work & who doesn't understand every assumption you've made about interactions, the risk compounds. Moving from a retained mode DOM-manipulating view of the page to a immediate mode v-dom backed view such as react can save a huge amount of trouble. That just deciding & justifying your decision that only a small tool is required is complex that I'm more in favor of using React everywhere than I was before you posted: this oversimplification & overreduction emphasizes to me how particular & careful you have to be about justifying picking a less-safe tool. Simply tallying up the state you need is far beside the point. The DOM's risk has always been more about compound interactions. If you have completely isolated things on the page that only need a couple fixed features, and you never plan to grow the capabilities, maybe conventional DOM swizzling is ok. I still find it hard to recommend.