preface

I wrote this because when I learned about DOM, I found that many documents, or people who knew DOM well, explained the concept of DOM in terse technical terms that newcomers could not understand, let alone understand. Most people learn a series of DOM manipulations, but don’t understand the concept of DOM. Other interpretations on the web, most of them just give you a DOM tree and tell you, this is the DOM. Or big swing DOM manipulation, to give you a more confusing concept. The following is for personal understanding, if any mistakes, welcome to correct or discuss. I hope it’s helpful for new people.

The body of the

Many documents explain something like this:

DOM (Document Object Model) is an abstract Model of Document content (HTML or XML) in programming languages. It models the content and structure of documents and provides programming languages with a complete set of API for manipulating documents.

This sentence is perfectly true in itself, but difficult for those new to the concept to understand. Let’s talk about why we need the DOM and see what it is.

In the ancient days before JAVASCRIPT, there was no need to modify the content of a document. Browsers parsed and rendered the content once and didn’t care about the document because it couldn’t change. There was no DOM.

JS may modify the document as it becomes available, and the browser needs to reflect these changes in real time.

So, after the browser parses the document, it also keeps track of the changes. Imagine that, without the DOM, JS should modify the string content of the document directly, which would be a disaster.

  1. First, dealing with large HTML text in JS is always tedious and error-prone, and no one wants to do that.

  2. Even, this aspect in JS, you are really good, fully competent for the job, the browser says it quit, good resolution, just put a big page found JS changed it, but don’t know where changed, only to parse the entire page, even if this change only adds a space, and there is no change the page content, This waste of performance is self-evident.

  3. Step back again, everything is fine in front, in the user’s opinion, every time you modify the document, the browser re-parses, the page must be white screen for a period of time, parsing time fast may be a flash screen, this experience is not as good as giving up modifying the page.

These three reasons explain the need for a convenient, efficient, traceable way to modify documents, and that’s what DOM does.

  1. On the browser side, when the browser parses the document for the first time, it parses the tags (text, etc.) in the document into nodes, and the parent elements and child elements (or text) are connected by lines. The whole document eventually forms a tree structure called DOM tree. The browser then renders the page according to the DOM tree. Browsers keep track of changes in the DOM tree, and as the tree changes, so does the page.

  2. The neat thing is that the DOM tree also exists in the JS environment (the JS execution engine is part of the browser), so changes to the document in JS are now simply changes to the DOM tree and its nodes. DOM node objects are ordinary JS objects with easy to manipulate methods and properties, so that manipulating documents in JS is as easy and quick as manipulating objects. Also, the browser will know which node you have modified, so you only need to re-render the parts of the page affected by the modification (i.e., backflow or redraw).

Later, the DOM component evolved into a separate specification independent of the browser and JS, providing a complete set of interfaces for accessing and modifying documents. These apis are widely used in browsers, but also support Python and others. The DOM standard is maintained by the W3C and is currently DOM 4.

So the term DOM has two meanings. The first is a tree modeled from the document, the DOM tree, from the perspective of the browser. From a programming language perspective, it provides a set of apis for manipulating documents. As a programmer, it’s more the latter.