Food for Thought

I was about to shut down my day’s activity and hit a lode of gold mine about HTML’s DOM. Yes, this post is about the innards of DOM vis-à-vis modern front-end frameworks (precisely angular15 and react). If there is anything close to a revolution in the web it is the invention of DOM in 1998 [history]. We seem to be throwing this abbreviation quite often in the recent web diaspora and are going to dive into this. As it concludes, this post assumes the reader has a basic knowledge of Angular and React.

What is DOM?

D stands for the HTML Document. We disperse information through documents. This document can be HTML, Word Doc, etc. Here we have meta-data called hypertext that describes raw text’s look and feel. Let’s see what is Object Model in DOM – The HTML document is inert text if it is not without the object model. Why? Each HTML element is instantiated as a JavaScript node object (instance of a class) and finally, we get the tree of node objects that reflects the structure of the HTML doc but with live things. Refer to the diagram below- the left side is an HTML doc but the right side is the nested object model which contains node objects with properties as key-value pairs.

The Performance Cost of DOM Manipulation

We might have heard this clichéd statement that “DOM manipulation is costly”. But, why?

Let’s say, you update the size of a button or styling color of a CSS class that decorates the button or delete/insert 1000 elements randomly in the DOM node tree – all the above actions are inconsequential at the DOM level (the computer-generated representation of the HTML document with live JavaScript Objects). But, on the other side of the world, which is rendering those changes that we hypothetically listed above has cascading effects. Which here might be layout/reflowing the content in the viewport.

Excerpt from Mozilla site: Layout performance is impacted by the DOM — the greater the number of nodes, the longer layout takes. Layout can become a bottleneck, leading to jank [1] if required during scrolling or other animations. While a 20ms delay on load or orientation change may be fine, it will lead to jank [1] on animation or scroll. Any time the render tree is modified, such as by added nodes, altered content, or updated box model styles on a node, layout occurs.

As a side note, we briefly discuss the word jank in the design nutcracker post here.

As a final word, programmatically manipulating the DOM is fast and easy but the cascading repercussions of the layout/reflow process and rendering are what cause performance bottleneck issues called jank.

How Angular15 & React solve the costly DOM Manipulation?

This part assumes to a certain extent the reader is familiar with the data-binding algorithms with both Angular15 and react. That said, despite hailing from an Angular1 and Angular2-15 background, Angular15’s algorithm (Change Detection) is a brute force and a shot-gun approach. Rather than operating with a scalpel, like in React. Why? The difference between Angular15 and React is how the data-binding is achieved. Angular15 doesn’t have precise control over which node element in the DOM gets updated- in the sense that with all the OnPush advancement, which fires the Change Detection only on selected branches or sub-branches, yea it can be controlled only by opting in/out branches or sub-branches. Unlike Angular15, React is more precise. Why? Since React’s Virtual DOM is a lighter version of a copy of DOM, the data updates are applied to copies of Virtual DOM (from there, it is passed/relayed on to the actual DOM) by the diffing algorithm [1]. A separate process then works on the virtual DOMs (works on multiple copies of the original virtual DOM and with updated/modified copies of virtual DOM) and consolidates (fine-grained optimization) the changes to apply on real DOM in one shot. This should save the reflow/layout issues we talked about in the previous paragraph.

Is it just a coincidence that there is a surplus of front-end frameworks trying to solve the same problem?