But why’s the browser DOM still so slow after 10 years of effort?

When you change something in the DOM it can have myriad side-effects to do with recalculating layouts, style sheets etc.

This isn’t the only reason: when you set element.innerHTML=x you are no longer dealing with ordinary “store a value here” variables, but with special objects which update a load of internal state in the browser when you set them.

The full implications of element.innerHTML=x are enormous. Rough overview:

  • parse x as HTML
  • ask browser extensions for permission
  • destroy existing child nodes of element
  • create child nodes
  • recompute styles which are defined in terms of parent-child relationships
  • recompute physical dimensions of page elements
  • notify browser extensions of the change
  • update Javascript variables which are handles to real DOM nodes

All these updates have to go through an API which bridges Javascript and the HTML engine. One reason that Javascript is so fast these days is that we compile it to some faster language or even machine code, masses of optimisations happen because the behaviour of the values is well-defined. When working through the DOM API, none of this is possible. Speedups elsewhere have left the DOM behind.

Leave a Comment