Why virtual Dom is a better one

Note: Virtual DOM is just a scenario for implementing MVVM, or a strategy for view updating. There is no virtual dom better than MVVM one says.

We review the traditional MVC framework, such as backbone, which compiles a template into a template function and needs to be updated by manually passing the data into the template function, getting a string, and refreshing a container with innerhtml! Note that here can actually be optimized, but because it is manual, it is physical activity, Is the use of very extensive innerhtml (using jquery HTML method performance will be worse, but the advantage is that it handles the innerHTML bug in IE and the whole platform can not execute the internal script tag bug) because of the overall replacement, all of a sudden destroy so many elements ( Sometimes tying events, which can cause GC problems, and inserting so many elements, and then rebinding events (this can be mitigated with the event proxy), so the performance is very poor

Scenario Two is a angular that uses dirty detection, requires a diff of all scope objects, and uses the notification refresh function to update the view. The more instructions on the page, the more data you need to compare (there are loops that need to be multiplied by the array length or the number of object key pairs) and may be used for too long to cause the page to feign death

Scenario three uses a sealed cabin scheme such as Avalon (the bottom of the ship is divided into separate areas, and local damage will not cause the wreck). Avalon uses Object.defineproperty and VBS to implement property monitoring so that when the user repairs the data, it can immediately enter the event bus system (Observer mode) and then obtain an array of subscribers associated with this attribute (in other words, the seal compartment, unlike Ng, a $ The scope object is an array of $ $watcher. In general, a property in a VM can only be used in a few places in the view, so several of the binding objects are generated in the corresponding subscriber array, and each Subscriber array is not too long. Therefore, synchronizing the view does not result in the traversal of the array too long and suspended animation. So Ng is prone to problems when dealing with pages of 2000 instructions (a grid, which tends to have two or three loops, can go up to 5,000 commands), and Avalon's containment plan is capable of supporting 12,000 instructions.

However, Avalon needs to save a large number of bound objects, and to convert the normal properties to accessor properties, it also requires memory, which is a space-time-changing scheme. However, Avalon has not been very good at handling ms-repeat, Ms-with, Ms-each these cyclic binding occasions. This creates a large number of proxy VMs, and the entire page is slowed down in the build destroy VM (even if the various pools are used for recycling).

Scenario Four, like knockout, makes the user miserable when used, wrapping up a function (wrapper) with a synchronized view, and refreshing the view, just call the wrapper again. All new MVVM now learns to rely on the collection from KO. This wraper informs its dependent wrapper, enters the event bus in an extremely painful and obscure way, and executes the view refresh function. Knockout is the use of closures to the extreme of the library, obviously this performance is also very poor.

Finally react, the first use of the compilation method (JSX virtual DOM conversion), this part of the consumption can be released early, but the string (jsx template) converted to a JS object, also accounted for not much memory. Then the data changes, because the data changes are required by the SetState method, so compatibility is good, less the consumption of object.defineproperty or wrapper, and then the corresponding data through render converted to a string, the string and then convert the virtual DOM tree The virtual DOM is compared to update the view.

React is a component-oriented design, a component is a sealed cabin, rarely compared to all virtual DOM, due to the forced use of one-way flow, reduce the need for each change diff. There is an issue with high memory consumption for bound objects and wrapper.

The popularity of react, just Ng is too difficult to use, when NG or other MVVM instead of using virtual DOM for view updates, this advantage does not need!

React the problem is obvious, the library is very large, it basically left the JSX converter will not live. Such a large library, in other words, you can change the more places, each version of a thousands of changes. As an architect, we need to have a very familiar understanding of its source code, or the problem can not be dealt with on their own, each time the foreigner reply is late.

The complexity of react, it is easy to trigger the reconstruction of it, even if the possessor has a forward-compatible desire, but can withstand several temptations, so after several versions will be unrecognizable. If you insist on the same, then other people will be on the hill, open-source things are easy to appear a more advantageous imitation! The implementation of react is very bad, strong in design!

The difficulty with virtual DOM is how to turn a string into a template function and then convert it to a virtual DOM. There is no simple HTML parser implementation, StackOverflow said can not use a few lines of the regular will be able to split html! So this high threshold leads to react alternatives to Dystocia! There are many self-proclaimed frameworks using virtual DOM on GitHub, not fake or super-garbage implementations! What's more, react supports custom tags, so it's not just a matter of parsing HTML, you need to do more with your custom tags!

Currently Avalon's Virtual DOM program is also slowly advancing, not I will not write parser, just too many people ask me many Avalon basic problems, seriously slowing my speed ....

Why virtual Dom is a better one