concept virtual dom in category react
This is an excerpt from Manning's book Isomorphic Web Applications: Universal Development with React.
The virtual DOM is a lightweight representation of the DOM that can be traversed and updated much faster. It’s a JavaScript representation of the DOM. For the button example, React keeps a version of the component structure in JavaScript.
Traditionally, manipulating the DOM has been slow. When a change needs to be made, the entire page has to be traversed, and updates are inserted and then rerendered. Imagine that you want to update a list of items in HTML. You’d have to find the list, traverse it, and make updates and insertions as needed. As your app grows and you have more items and more lists, this process gets slower. Enter the virtual DOM.
This is an excerpt from Manning's book React in Action.
One of the major pieces of technology driving this is the virtual DOM. A virtual DOM is a data structure or collection of data structures that mimics or mirrors the Document Object Model that exists in browsers. I say a virtual DOM because other frameworks such as Ember employ their own implementation of a similar technology. In general, a virtual DOM will serve as an intermediate layer between the application code and the browser DOM. The virtual DOM allows the complexity of change detection and management to be hidden from the developer and moved to a specialized layer of abstraction. In the next sections, we’ll look from a high level at how this works in React. Figure 1.3 shows a simplified overview of the DOM and virtual DOM relationship that we’ll explore shortly.
The web APIs in browsers let us interact with web documents with JavaScript via the DOM. But if we can already do this, why do we need something else in between? I want to first state that React’s implementation of a virtual DOM doesn’t mean that the regular web APIs are bad or inferior to React. Without them, React can’t work. There are, however, certain pain points of working directly with the DOM in larger web applications. Generally, these pain points arise in the area of change detection. When data changes, we want to update the UI to reflect that. Doing that in a way that’s efficient and easy to think about can be difficult, so React aims to solve that problem.
Part of the reason for that problem is the way browsers handle interactions with the DOM. When a DOM element is accessed, modified, or created, the browser is often performing a query across a structured tree to find a given element. That’s just to access an element, which is usually only the first part of an update. More often than not, it may have to reperform layout, sizing, and other actions as part of a mutation—all of which can tend to be computationally expensive. A virtual DOM won’t get you around this, but it can help updates to the DOM be optimized to account for these constraints.
When creating and managing a sizeable application that deals with data that changes over time, many changes to the DOM may be required, and often these changes can conflict or are done in a less-than-optimal way. That can result in an overly complicated system that’s difficult for engineers to work on and likely a subpar experience for users—lose-lose. Thus performance is another key consideration in React’s design and implementation. Implementing a virtual DOM helps address this, but it should be noted that it’s designed to be just “fast enough.” A robust API, simple mental model, and other things like cross-browser compatibility end up being more important outcomes of React’s virtual DOM than an extreme focus on performance. The reason I make this point is that you may hear the virtual DOM talked about as a sort of silver bullet for performance. It is performant, but it’s no magic performance bullet, and at the end of the day, many of its other benefits are more important for working with React.