3 ms·

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

by 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

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.