Yu Yuxi
Links: http://www.zhihu.com/question/31809713/answer/53544875
Source: know
Copyright belongs to the author, please contact the author for Authorization.
1. Native DOM operations vs. framework Encapsulation Operations.
This is a tradeoff between performance vs. Maintainability. The meaning of the framework is to cover up the underlying DOM operations, allowing you to describe your purpose in a more declarative way, making your code easier to Maintain. There is no framework that can be faster than purely manual, optimized Dom operations, because the DOM operations layer of the framework needs to deal with any actions that may be generated by any upper-level API, and its implementation must be Pervasive. For any one benchmark, I can write faster manual optimizations than any frame, but what's the point? Do you do manual optimization for every place when building a real application? This is obviously impossible due to maintainability considerations. The framework gives you the assurance that, without the need for manual optimization, I can still give you a decent performance.
2. Misunderstanding of React's Virtual DOM.
React never said "React is faster than native operation DOM." React's Basic thinking pattern is to re-render the entire application every time there is a change. If there is no Virtual DOM, the simple thing to do is to reset InnerHTML directly. Many people do not realize that in a large list of all the data has changed, resetting the InnerHTML is actually a reasonable operation ... The real problem is that in "all re-rendering" thinking mode, even if only one row of data changes, It also needs to reset the entire innerHTML, this time obviously there is a lot of waste.
We can compare the redraw performance consumption of InnerHTML vs. Virtual DOM:
- Innerhtml:render HTML string o (template size) + recreate all DOM elements o (dom size)
- Virtual Dom:render virtual Dom + diff o (template size) + necessary dom update o (dom change)
Virtual DOM Render + diff is obviously slower than rendering HTML strings, but! It is still a purely js-level calculation, which is still much cheaper than the DOM operations behind it. As you can see, the total calculation of InnerHTML is related to the size of the entire interface, whether it is JS or Dom operations, but in the computational amount of Virtual dom, only the JS computation is related to the interface size, and the DOM operation is related to the amount of data change. As I said earlier, the JS calculation is extremely inexpensive compared to DOM operations. That's Why you have Virtual DOM: it guarantees 1) no matter how much your data changes, the performance of each redraw is acceptable; 2) you can still write your application in a similar way as innerHTML.
3. MVVM vs. Virtual DOM
Compared to React, other MVVM frameworks such as Angular, Knockout, and Vue, Avalon use data binding: by directive/binding objects, observing data changes and preserving references to actual DOM elements, when data changes The corresponding Operation. The change checking for MVVM is data-level, and the React check is the DOM structure level. The performance of MVVM varies according to the implementation principle of the change detection: Angular's dirty Check makes any changes have a fixed
O (watcher Count)Knockout/vue/avalon are used for dependency collection, both at the JS and DOM levels.
O (change)：
- Dirty Check: Scope Digest o (watcher count) + necessary dom update o (dom change)
- Dependency collection: re-collect dependent o (data change) + necessary dom update o (dom change)
As you can see, the most inefficient part of Angular is the performance cost associated with any small change and watcher Quantity. But! When all the data is changed, Angular is not really a disadvantage. Dependency collection needs to be re-collected when initializing and changing data, which can be negligible at a small update, but consumes when the volume of data is Large.
When MVVM renders a list, because each row has its own data scope, it usually has a corresponding ViewModel instance for each row, or a slightly lighter number of "scope" objects that take advantage of the prototype, but at some Cost. so, the initialization of the MVVM list rendering is almost certainly slower than React, because creating an Viewmodel/scope instance is much more expensive than the Virtual DOM. A common problem with all MVVM implementations here is how to efficiently reuse the ViewModel instances and DOM elements that have been created when the data source changes are rendered in the list, especially when the data is a completely new object. Without any reuse optimizations, because the data is "completely new", MVVM actually needs to destroy all previous instances, recreate all instances, and then render again! This is why the Angular/knockout implementations of links in the topic are relatively slow. In contrast, React's change checking is a DOM-structured one, and even new data, as long as the final rendering has not changed, does not need to be worked Hard.
Both Angular and Vue provide an optimization mechanism for list redrawing, which is how the hint framework effectively re-uses instances and DOM Elements. For example, the same object in the database, the two-time front-end API calls will be different objects, but they still have the same uid. At this point you can prompt the track by UID to let Angular know that the two objects are actually the same Data. So the original data corresponding to the instance and DOM elements can be reused, only need to update the changed Parts. alternatively, you can directly track the by $index to "reuse in Situ": directly based on the position in the array to be Reused. In the example given in the topic, if the angular implementation plus track by $index, the subsequent redraw will not be much slower than the React. Even in the Dbmonster test, Angular and Vue used track by $index later than React: Dbmon (note Angular default version is not optimized, optimized Below)
By the way, React renders the list with the special prop of key, which is essentially the same thing as Track-by.
4. Performance Comparison also depends on the occasion
When comparing performance, it is very clear that the initial rendering, the small amount of data updates, and the large number of data updates are different occasions. Virtual DOM, dirty-check mvvm, data-collection MVVM have different performance and different optimization requirements on different occasions. Virtual DOM also requires targeted optimizations, such as shouldcomponentupdate or immutable data, to improve the performance of small data updates.
- Initial rendering: Virtual DOM > Dirty Check >= Dependency Collection
- Small Data update: Dependency collection >> virtual dom + optimization > Dirty check (unable to Optimize) > Virtual dom No optimizations
- Massive data update: dirty Check + optimized >= dependency collection + optimization > Virtual DOM (no/no optimization) >> MVVM No optimizations
Don't be naïve to think that Virtual DOM is fast, diff is not free, batching MVVM can do it, and the final patch is not to use the native API. In my opinion, the real value of Virtual DOM is never performance, but it's 1) opens the door for functional UI programming, 2) can render to backend outside the dom, such as Reactnative.
5. Summary
These comparisons are more of a reference to the framework development researcher. The mainstream framework + reasonable optimization is sufficient to meet the performance requirements of most applications. If the performance has the extreme demand for the special situation, in fact, should sacrifice some maintainability to take manual optimization: for example, the Atom editor in the implementation of file rendering to abandon the React and adopt their own implementation of the tile-based rendering, such as the mobile side need Dom-pooling virtual scrolling, does not need to consider order changes, can bypass the framework of the built-in implementation of their own to engage in one.
Reactjs compared to the native scheme is absolutely fast? Under what circumstances react has the advantage
