One of the misconceptions circulating among the young generation of web developers, and not only them, is the belief that the DOM is actually the same HTML, just in the browser. This misconception is further fueled by the fact that the browser's DOM inspector displays everything within the webpage as the good old hypertext markup, adding more confusion to the understanding of these things.
So, as I loudly declare today: "DOM is not HTML.", the question arises, "What is it, then?" Let's try to figure it out together.
First, let's look at the dry academic definition. DOM (Document Object Model) is a programming interface that allows programs to dynamically access and update a document's content, structure, and styles. The DOM represents the document as a data structure, such as a tree, where each node is an object representing a part of the document, such as an element, attribute, or text content. Does this make a bit more sense? If you answered "yes," then I have every reason to suspect you have a bit of a pedant in you who loved "Legends and Myths of Ancient Greece" as a favourite book in kindergarten. Wait, that's about me... Oh, never mind, let's try to explain it more simply.
Let's imagine that HTML tags are images of LEGO blocks, and HTML attributes in this example are different characteristics of these images: colour, orientation in space, etc. Then our HTML documents are those instruction booklets from which you can assemble what's illustrated, like the Millennium Falcon, and then, if desired and inspired, a deep-sea pterodactyl with a pedal drive and a nuclear warhead in its butt.
And the DOM is what you've assembled from the real blocks, which you can touch with your hands. As in a construction set, each part, a DOM node, is a piece of a complex hierarchy, simultaneously having conventionally parental and child structures. You can imagine this hierarchy in various ways, so for simplification, let's imagine that our LEGO is at least four-dimensional and can simultaneously have both flat and spatial relationships.
Just as you can find the necessary part in the already assembled constructor (well, when you were assembling and realized three packets ago that you missed inserting the green block), you can also find the required element in the DOM. Moreover, you can find many different elements simultaneously based on various attributes, usually id, tag name, class, attribute value, and others.
Moreover, you can not only find these elements but also perform various useful actions with them! For instance, you can replace some blocks with others, add new ones, remove unnecessary ones, and even change the properties of these blocks. In a real constructor, this wouldn't work, but if it did, then you could. After all, we have an imaginary, four-dimensional LEGO, so let it be.
And just like a real LEGO constructor, the DOM can be genuinely interactive, i.e., it can respond to user actions. Just like in those expensive sets where you can assemble a working Lamborghini model at a 1:24 scale, with a beeping horn, a buzzing engine, opening-closing doors, and imaginary cocaine spilt on the passenger seat. I'm talking about DOM events here, not cocaine, but the fact that the DOM can handle events. For example, you press a hypothetical door, and it opens. So it is in the DOM — you press a button, an event is triggered, and you can subscribe to it, opening hypothetical doors. There are many events in the DOM, and all of them are very interesting, and now you can even create your custom events, not limited to standard ones.
So what am I saying? The DOM is not HTML but a completely separate thing that has a whole range of properties unique to it, and thanks to them, we can create attractive, interesting, and diverse web applications.
Top comments (8)
DOM is awesome, really it is.
But why in modern JS frameworks the virtual DOM is in use?
Without a virtual DOM, the entire webpage would need to be re-rendered every time the DOM changes. This can be inefficient and lead to slower performance, especially for complex UIs. The virtual DOM helps optimize this process by updating only the parts of the actual DOM that have changed, improving efficiency and performance.
Not quite, we can do the same efficient and performant dom updating or UI updating with the real dom or normal dom, libraries like morphdom for example do this exactly, it has nothing to do with the dom being real or virtual, just virtual dom is the idea that the real dom is heavier on memory and to manipulate than just an alternative js structure that imitates it, a.k.a virtual dom, this also helps in a process called dom diffing, where we compare both the real dom and the virtual dom to realize what has changed and rerender UI efficiently, but this can still be done between two real doms... hope I have clarified, check out my framework it uses real dom using morphdom and rerenders UI efficiently: github.com/Z-Js-Framework/z-js
interesting question, indeed!
Great article!!
awesome series 😎
please, continue
We need the same info about BOM as well. Keep up the great work!
We should not forget, that the DOM is just a database, that contains the recipie for a web site (not mentioning the interaction between CSS and the DOM). Above this, there is the beautiful and very sophisticated machine we call the browser, which not only knows how to render the content, but also cares for a flawless user experience. If we change the DOM (which is usually extremely fast), the browser decides how and when to react.
Building the DOM - regardless if you do it programmatically or if the browser parses an HTML-document - is usually done in milliseconds. Rendering and file interactions usually take much longer. Therefore - in most cases - DOM performance does not matter for the page performance. It is fast anyway.