Why is IMBA so fast?

This column is ill-thought-out. Imba programme document

Here are some comments from vUE authors about the virtual DOM:

When comparing performance, distinguish between initial rendering, small data updates, and large data updates. Virtual DOM, dirty check MVVM, data collection MVVM have different performance and different optimization requirements in different situations. The Virtual DOM also needs specific optimizations, such as shouldComponentUpdate or IMmutable data, to improve the performance of small data updates. Initial render: Virtual DOM > Dirty Check >= Dependency collection

Small amount of data updates: Dependency collection >> Virtual DOM + Optimization > Dirty Check (Unable to Optimize) > Virtual DOM No optimization

Massive data updates: Dirty check + optimization >= Dependent collection + Optimization > Virtual DOM (unavailable/no optimization required) >> MVVM No optimization

Don’t be fooled into thinking that Virtual DOM is fast, diff is not free, batching and MVVM can do it, and eventually patch will have to use native apis. In my opinion, the real value of Virtual DOM has never been performance, but 1) it opens the door to functional UI programming; 2) Can render to backend other than DOM, such as ReactNative.

Author: especially the rain stream links: www.zhihu.com/question/31… The copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please indicate the source.

The reason IMBA is so fast is that it relies on collection + real DOM manipulation, so that each change can be made to the DOM precisely, i.e.