The article shared by @hipkiss91 is indeed an excellent resource to get a better understanding of how browsers work under the hood.

Thank you for sharing the link, @chilimatic. The diagram he is referring to is this one, the workflow of a browser's rendering engine:

Here is an excerpt from the How Browsers Work article, that answers your particular question:

While the DOM tree is being constructed, the browser constructs another tree, the render tree. This tree is of visual elements in the order in which they will be displayed. It is the visual representation of the document. The purpose of this tree is to enable painting the contents in their correct order.

Firefox calls the elements in the render tree "frames". WebKit uses the term renderer or render object. A renderer knows how to lay out and paint itself and its children. WebKit's RenderObject class, the base class of the renderers, has the following definition:

class RenderObject{
  virtual void layout();
  virtual void paint(PaintInfo);
  virtual void rect repaintRect();
  Node* node;  //the DOM node
  RenderStyle* style;  // the computed style
  RenderLayer* containgLayer; //the containing z-index layer
}

So in your case, here is a very high-level overview of what exactly happens — as soon as you change the innerHTML attribute; the DOM tree is updated, and further along the flow, styles are attached to the node, creating a render object; which would be replaced with the corresponding old node in the Render Tree. Whenever there is a change, the render tree is traversed, and for all the visible render objects, their corresponding paint methods are called.

The thing is, the browser and the JS API you are using are directly wired. Where do you think the document and window come from? Why are they not in Node.JS? I think, it's easy to explain using Node.JS's VM module:

The VM module lets you run a script in a separated container, a sandbox, or however you'd like to call it. A similar functionality is exposed by JS interpreter libraries, like Google's V8, to lower-level programmers (in C++).

const vm = require('vm');

The initial global scope is empty. There is no JSON, there is no window, there is no document, there is no setTimeout, there is no nothing. In JS-terms, it would look like {}, not counting standard object methods and properties. So they add functions and objects with methods, implement them and, that way, can wire the render code directly to whatever you might write. A very simplistic example might look like the following snipped, with pseudo-code, entirely implemented in JS (normally it would happen in C++) for your convenience:

const sandbox = {
  document: {
    getElementById: function(id) {
      // find element and return it as a new object
      return {
        // The following line is a setter: developer.mozilla.org/en-US/docs/Web/JavaScript/R…
        set innerHTML(html) {
          // repaint website
        },
        // various other properties
      };
    },
  },
  // various other functions and objects
};

const context = new vm.createContext(sandbox);
const script = new vm.Script(youJSFileHere);

// and execute some JS file you included in your HTML
script.runInContext(context);

This article may be of use. It explains how browsers work and goes through the entire process from start to finish :)

sai did a story about the virtual dom where he posted a video about the dom rendering engines :)

here is a diagram

hashnode.com/post/the-one-thing-that-no-one-prope…