I'm not sure how those would deal with the scenarios focused on in the article. The only one I'm familiar with is per-component redraws which wouldn't apply.
The general gist is that one would use the subtree diff skipping APIs to prevent expensive diffs, and per-component redraws to selectively update things in the problematic subtree. Admittedly, it's not perfect and requires a not-so-trivial amount of app-space code, but at least it's not a black box renderer like, say, Angular 1.
Ultimately, there are a vast number of different scenarios, some of which are likely to remain open problems for the foreseable future (e.g. a 100,000 item reverse), and some of which can be worked around via application space "escape hatches" such as the use of granular update APIs and techniques like occlusion culling.
As I said, it's very interesting to see work that tackles the problem from an algorithmic complexity angle, and it's always healthy to explore different performance characteristics, but I think it's important to also keep in perspective what is the performance profile of solutions currently in the market, because looking at their theoretical algorithmic complexity alone doesn't tell the whole story.
Ultimately, there are a vast number of different scenarios, some of which are likely to remain open problems for the foreseable future (e.g. a 100,000 item reverse), and some of which can be worked around via application space "escape hatches" such as the use of granular update APIs and techniques like occlusion culling.
As I said, it's very interesting to see work that tackles the problem from an algorithmic complexity angle, and it's always healthy to explore different performance characteristics, but I think it's important to also keep in perspective what is the performance profile of solutions currently in the market, because looking at their theoretical algorithmic complexity alone doesn't tell the whole story.