Yup. Each page has a DOM tree, with the document at the top or “root” of the (inverted) tree. The Model (M in DOM) allows the browser to offer a way to programmatically modify what it displays on the screen. It’s what you’re using with a “document.getElementByID()” call. A DOM is offered by the browser for each page/tab open, and accounts for all elements, even those made to take up no space by setting “display: none;” as a style.
Back when the web started, all that existed was simple HTML: if an element was defined in the .html file, it was displayed, which involved calculating the layout and rendering it on the screen. The only reason to redraw the page was if the text of the page changed, equivalent to an F5/Refresh event.
Any changes to the DOM tree require that the browser lays out and draws the page again. This is why we consider manipulation of the DOM inefficient.
If you are Facebook (which invented React), and you need to update with two new comments, and 5 new counts for likes/dislikes on the ten comments to a post, then you might have to make the browser redraw the whole page 7 times (and once again each time something small like that changes). Enter the virtual DOM, something the React framework creates for you, the programmer. It holds the representation of the “current state” of the page, but doesn’t re-render the whole page every time you change some little thing.
Instead, the React Virtual DOM decides for you when to tell the browser to redraw the page. Changes are batched for efficiency, and multiple updates are pushed through when it decides to call the render() method in response to state changes. This is why you can’t assume that calls to this.setState() have gone through in the same method that updates it. Accessing this.state in that same chunk of code is risky. You either have to have a local variable hold the representation in parallel, or you have to use the variant of this.setState that lets you access the prevState ( which is what I often do to be sure my code works clean ).
Edit: Forgot to include my sources/further reading.
- You can start reading at the “Going further with the Virtual DOM” section
- A more detailed explanation, but a granular one, is in the references to that article (link #2):