The concept of the Virtual DOM is well known, and it is intended to ease browser DOM manipulation, resulting in improved performance, and then has the nice side effect of implementing cross-platform rendering.

Cross-platform is just a side effect, but many people understand it as the design purpose of VDom. This kind of cognition puts the cart before the horse, so many people do not know the optimization function of VDom. Here is the development history of VDom.

Facebook was a failed attempt in the early 2000s

In 2000, iPhone had become synonymous with mobile phones. Internet companies that had enjoyed great success on desktop platforms began to realize the advent of mobile era, especially Facebook, which made its fortune in social networking, actively deployed mobile Internet platforms.

At that time the Internet already there are signs of a unified, use the WebApp instead of desktop software has gradually become a popular trend, naturally these Internet ceos also want to which a copy to the mobile terminal of the desktop, thanks to the iPhone has the most outstanding mobile browser makes this idea probably still can be achieved. So Facebook started working on an H5 WebApp for mobile.

Although iPhone had the best mobile browser at the time and was the first to support H5, due to the hardware configuration and weak mobile operating system at that time, Facebook encountered great resistance when developing H5 applications. The most critical resistance was as a social company. The large number of user comments was a threshold that had to be overcome, and it was easy to overcome on the desktop, which was already overloaded with performance and was not a problem for a lot of data processing. However, when it came to the mobile end, the display of a large number of messages was a huge drain on memory. Coupled with the lack of hardware at the time, the entire H5 app was quite silly to use, unlike the original iPhone app.

It should also be mentioned that at that time Steve Jobs did not open up the SDK for developers to develop native apps, the only third party could develop H5 apps, isn’t it amazing, Joe is the first to propose WebApp. Later, Apple realized that the iPhone wasn’t powerful enough to support H5 applications, and slowly opened up the SDK to third-party developers.

That is to say, have a face book early, was a great decline, the compromise finally like native applications, after all, money is king, it’s no good to lose face, later for a long time, zuckerberg also preached native applications, belittling H5 application, Joe master also happy to see the results, with the native SDK development then is apple’s exclusive application, So why not?

On facebook renounced H5 technology about two weeks after the switch to the native SDK, there are two technical enthusiasts to imitate the H5 application of facebook, and the effect of the demo unexpected good, they are optimized for H5 applications, using similar to apple UITable rendering techniques, rendering the user sees only that part of the data, Don’t render what you don’t see, and the scrolling performance of lists is almost as good as native apps, which makes you feel like Facebook technology isn’t working, and you switched to native apps because there aren’t good people.

React’s rise

Although H5 applications are not developed on mobile phones for the time being, desktop applications are still the mainstream at that time, and as the number of users continues to increase, performance bottlenecks gradually appear on desktop. For this reason, Facebook is trying new ways to optimize the front end while optimizing the back end. Many of the most popular front-end development ideas emerged from that time.

New ideas for new technologies like one-way data delivery and virtual Dom have helped Facebook leap forward on the desktop. Virtual DOM technology has changed the whole front – end development idea.

Angular is probably the most popular at that time. Its out-of-the-box concept greatly facilitates front-end developers. However, Angular only provides a framework tool for MVVM, which is still stereotypical for the underlying DOM processing. But it can be difficult to handle large amounts of data.

Angular introduced React to Angular, and it worked surprisingly well. With the help of Angular’s MVVM feature and the React virtual DOM, big data processing has improved dramatically. After that the Angualr community went to work on Angular2 and then there was no more. Who cares about a project that was pushed back to the beginning?

React, however, is alive and well. Its performance is obvious. Even if your code is poorly written, React will save you half of your life. React now lets Facebook go back to mobile and double down on its humiliation. Since then which frame said he did not HAVE VDom I am afraid are difficult to establish a foothold in the river’s lake.

Why is Virtual DOM useful

Browser for greater influence on the performance of most is to list the type of application, the traditional approach, whether you are shows a data or article ten thousand of the data is loaded directly to the DOM, if is a all inserted into the DOM was fine, but if a a insert the browser shows that I’ve been card dead, Because DOM manipulation is time consuming and memory consuming.

There are two ways to solve this problem. The first is to use Virtual Scroll technology, which is used for UITable and UIList. The technology detects the current window size, reads and renders data that can be seen by the user. By the way, read more data from the back and front to facilitate the smooth display of scrolling. This is actually a good way to save memory and perform well, which was great when you looked at the original iPhone.

Although Virtual Scroll is good, but a bit of a waste of the browser itself, after all, Apple’s framework itself is responsible for rendering, and we write a front-end has to be responsible for rendering obviously superfluous, then what else? This is the idea of Virtual DOM. Maintain a Virtual DOM tree in memory, and extract the parts that need to be updated into the real DOM tree. There’s an even easier way to do this. You could represent the DOM with a string, and you could just replace it with innerHTML. But if you have a large number of strings, performance drops dramatically. However, direct DOM operation does not need this successive step. After measuring, it is more cost-effective to use Virtual DOM method.

Side effects of Virtual DOM

When it comes to side effects, most people think of them as bad things. Virtual DOM has the opposite side effect, but one good side effect is cross-platform rendering. Because all render data is actually stored in memory, React maintains its own render tree, so with proper adaptation it can be ported to any render framework.