> Until very recently, re-rendering with virtual DOM diffing was considered more performant than direct, incremental DOM manipulation. This too, may no longer be true.
Actually wasn't strictly true even when React came out, but it was true enough with the code that most JS developers actually wrote to lead to a change in dominant JS framework.
DOM manipulation even in 2013 used a dirty-bit system. Calling element.appendChild would be a few pointer swaps and take a couple ns. However, if you then called any of a number of methods that forced a layout, it would re-render the whole page at a cost of ~20ms on mobile devices of the day. These included such common methods as getComputedStyle(), .offsetWidth, .offsetHeight, and many others - there was a list of about 2 dozen. Most JS apps of the day might have dozens to hundreds of these re-layouts triggered per frame, but the frame budget is only 16.667ms, so that's why you had slow animations & responsiveness for mobile web apps of 2013.
React didn't need a full virtual DOM layer. It just needed to ensure that all modifications to the DOM happened at once, and no user code ran in-between DOM manipulations within a certain frame. And sure enough, there are frameworks that actually do this with a much lighter virtual DOM abstraction (see: Preact) and get equal or better performance than React.
The lesson for performance tuning is to understand what's going on, don't just take benchmarks at face value. If a call is expensive, sometimes it's conditionally expensive based on other stuff you're doing, and there's a happy path that's much faster. Learn to leverage the happy paths and minimize the need to do expensive work over and over again, even if the expensive work happens in a layer you don't have access to.
Actually wasn't strictly true even when React came out, but it was true enough with the code that most JS developers actually wrote to lead to a change in dominant JS framework.
DOM manipulation even in 2013 used a dirty-bit system. Calling element.appendChild would be a few pointer swaps and take a couple ns. However, if you then called any of a number of methods that forced a layout, it would re-render the whole page at a cost of ~20ms on mobile devices of the day. These included such common methods as getComputedStyle(), .offsetWidth, .offsetHeight, and many others - there was a list of about 2 dozen. Most JS apps of the day might have dozens to hundreds of these re-layouts triggered per frame, but the frame budget is only 16.667ms, so that's why you had slow animations & responsiveness for mobile web apps of 2013.
React didn't need a full virtual DOM layer. It just needed to ensure that all modifications to the DOM happened at once, and no user code ran in-between DOM manipulations within a certain frame. And sure enough, there are frameworks that actually do this with a much lighter virtual DOM abstraction (see: Preact) and get equal or better performance than React.
The lesson for performance tuning is to understand what's going on, don't just take benchmarks at face value. If a call is expensive, sometimes it's conditionally expensive based on other stuff you're doing, and there's a happy path that's much faster. Learn to leverage the happy paths and minimize the need to do expensive work over and over again, even if the expensive work happens in a layer you don't have access to.