
Why is the DOM slow? - melsalvador
What can be added (or removed) to help to help it approach native responsiveness.<p>Please note, &quot;just get rid of it&quot; isn&#x27;t realistic. Given where we are, what can be done, that&#x27;s the challenge.
======
nostrademons
Sometime I want to do a big, detailed blog post full of supporting data on
this topic. Unfortunately, all the data I have on this I left behind at my ex-
employer (Google), and I don't yet have time to write the code to compile new
data.

The short answer is that the DOM is not slow. Adding & removing a DOM node is
a few pointer swaps, not much more than setting a property on the JS object.

However, _layout_ is slow. When you touch the DOM _in any way_ , you set a
dirty bit on the whole tree that tells the browser it needs to figure out
where everything goes again. When JS hands control back to the browser, it
invokes its layout algorithm (or more technically, it invokes its CSS recalc
algorithm, _then_ layout, then repaint, then re-compositing) to redraw the
screen. The layout algorithm is quite complex - read the CSS spec to
understand some of the rules - and that means it often has to make non-local
decisions.

Worse, layout is triggered synchronously by accessing certain properties.
Among those are getComputedStyleValue(), getBoundingClientWidth(),
.offsetWidth, .offsetHeight, etc, which makes them stupidly easy to run into.
Full list is here (possibly a few years out of date):

[http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-
in-...](http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-
webkit.html)

Because of this, a lot of Angular and JQuery code is stupidly slow. One layout
will blow your entire frame budget on a mobile device. When I measured Google
Instant c. 2013, it caused _13 layouts_ in one query, and locked up the screen
for nearly 2 seconds on a mobile device. (It's since been sped up.)

React doesn't help speed up layout - if you want butter-smooth animations on a
mobile web browser, you need to resort to other techniques like limiting
everything you do in a frame to operations that can be performed on the GPU.
But what it does do is ensure that there is at most one layout performed each
time you update the state of the page. That's often quite an improvement on
the status quo.

(Standard disclaimer: this was all current as of the beginning of 2014, but
browsers change fast, and it may or may not be current now. Much of the
current pitiful performance of major JS frameworks is because they were built
with assumptions on browser performance that were true in 2008, but aren't
now.)

~~~
shortoncash
This was a great comment, and I feel like I got a great education reading
this. Thanks again.

