3 ms·

I have a very DOM-heavy admin built in both jQuery, React, and Angular that uses the Django-style multi-select boxes (left panel has available options, right pa

I have a very DOM-heavy admin built in both jQuery, React, and Angular that uses the Django-style multi-select boxes (left panel has available options, right panel has selected options). Toggling options is instant in jQuery (explicit DOM manipulation)' ~50ms delayed in React (Fake DOM diff calculation), and Angular is ~500ms (dirty-check and re-render). Anyway, I find it interesting how it goes to show that different tools work best for different jobs. React seems to strike a nice balance between JavaScript and Angular Directives that makes complex, dynamic templating much easier.

jordwalke 13y ago
Eric, Are you using the prod version of React? The dev version includes helpful debugging checks that consume a lot of CPU - (But don't worry, it will never show up in production builds). I really like how you described React as "striking a balance". Here's how I think about that balance: 1. CPU time in React is an investment: What I've seen with large apps with complex css rules, is that the cost of performing even one additional style recalculation can cost upwards of 50ms - 75ms. If React invests an additional 10ms to find the absolute minimum number of DOM mutations and avoids even just one unnecessary style recalc, then we appreciate a great return on that investment. 2. If we run into a case where we're not seeing an outstanding return on that investment, we just use React's supported optimization hooks (shouldComponentUpdate). 3. React's API is unique in that it encourages optimizing for performance, but optimizing at the later stages of development, as opposed to the beginning stages. It's nice to develop rapidly and not let performance concerns interfere with the creative development process, while at the same time knowing that there is always a way to speed up the bottlenecks using the optimization hooks (if needed at all).

jordwalke 13y ago

Eric, Are you using the prod version of React? The dev version includes helpful debugging checks that consume a lot of CPU - (But don't worry, it will never show up in production builds). I really like how you described React as "striking a balance". Here's how I think about that balance: 1. CPU time in React is an investment: What I've seen with large apps with complex css rules, is that the cost of performing even one additional style recalculation can cost upwards of 50ms - 75ms. If React invests an additional 10ms to find the absolute minimum number of DOM mutations and avoids even just one unnecessary style recalc, then we appreciate a great return on that investment. 2. If we run into a case where we're not seeing an outstanding return on that investment, we just use React's supported optimization hooks (shouldComponentUpdate). 3. React's API is unique in that it encourages optimizing for performance, but optimizing at the later stages of development, as opposed to the beginning stages. It's nice to develop rapidly and not let performance concerns interfere with the creative development process, while at the same time knowing that there is always a way to speed up the bottlenecks using the optimization hooks (if needed at all).