Learning and understanding the DOM results in better ways of accessing, changing, and monitoring different elements of an HTML page. The Document Object Model may also help us reduce unnecessary increases in script execution time.
Before talking about what the DOM is, how it comes into existence, how it exists, and what happens inside of it, I want you to know about trees. Not the coniferous & deciduous kind but about the data structure tree.
It’s a lot easier to comprehend the concept of data structures if we simplify its definition. I would say, a data structure is about arranging your data. Yes, just plain old arrangement, as you would arrange the furniture in your house or books in a bookshelf or all the different food groups you’re having for a meal on your plate in order to make it meaningful to you.
Of course, that’s not all there is to a data structure, but that’s pretty much where it all starts. This “arrangement” is at the heart of it all. It’s pretty important in the DOM as well. But we’re not talking about DOM yet, so let me steer you towards a data structure that you might be familiar with: arrays.
Arrays have indices and length, they can be multi-dimensional, and have many more characteristics. As much as important it is to know these things about arrays, let’s not bother ourselves with that right now. To us, an array is pretty simple. It’s when you arrange different things in a line.
Similarly, when thinking of trees, let’s say, it’s about putting things below one another, starting with only one thing at the top.
Now, you might take the single line ducks from before, turn it upright, and tell me that “now, every duck is under another duck”. Is it a tree then? It is.
Depending on what your data is or how you’ll be using it, the topmost data in your tree (called the root) might be something that is of great importance or something that’s only there to enclose other elements underneath it.
Either way, the topmost element in a tree data structure does something very important. It provides a place to start searching for any information we want to extract from the tree.
So, this is basically the physical arrangement of DOM data in code: everything is arranged as objects. Logically, however, it’s a tree.
Every browser software has a program called DOM Parser that is responsible for parsing an HTML document into DOM.
Take a simple HTML file. It has the root element
. Its sub-elements are
, each has many child elements of their own.
So essentially, the browser reads the data in the HTML document, something similar to this:
And, arranges them into a DOM tree like this:
The representation of each HTML element (and its belonging content) in the DOM tree is known as a Node. The root node is the node of
document (since it’s the representation of the HTML document). Thus, we access the DOM tree of an HTML document through the
We can’t only access, but also manipulate the HTML document through the DOM. We can add elements to a web page, remove & update them. Each time we change or update any nodes in the DOM tree, it reflects on the web page.
The nodes of a DOM tree have certain characteristics or properties. Almost every node in a tree has a parent node (the node right above it), child nodes (the nodes below it) and siblings (other nodes belonging to the same parent). Having this family above, below, and around a node is what qualifies it as a part of a tree.
This family information of every node is saved as properties in the object representing that node. For example,
children is a property of a node that carries a list of the child elements of that node, thus logically arranging its child elements under the node.
As much as we may find updating the DOM useful (in order to modify a web page), there is such a thing as overdoing it.
Say, you want to update the color of a
But, what if you want to remove a node from a tree or add one to it? The whole tree might have to be rearranged, with the node removed or added to the tree. This is a costly job. It takes time and browser resource to get this job done.
For example, let’s say, you want to add five extra rows to a table. For every row, when its new nodes are created and added to the DOM, the tree is updated each time, adding up to five updates in total.
We can avoid this by using the
DocumentFragment interface. Think of it as a box that could hold all the five rows and be added to the tree. This way the five rows are added as one single piece of data and not one by one, leading to only one update in the tree.
This doesn’t only happen when we remove or add elements, but resizing an element can also affect other nodes, as the resized element might need other elements around it to adjust their size. So, the corresponding nodes of all the other elements will need to be updated and the HTML elements will be rendered again according to the new rules.
Likewise, when the layout of a web page as a whole is affected, a part or the whole of the web page might be re-rendered. This is process is known as Reflow. In order to avoid excessive reflow make sure you’re not changing the DOM too much. Changes to the DOM aren’t the only thing that can cause Reflow on a web page. Depending on the browser, other factors can contribute to it, too.