1. 18
  1.  

  2. 26

    Abstraction is more likely to increase speed, because someone smarter than you has written the bit that needs to be fast.

    Yeah, if the abstraction is well designed for performance. For example, Haskell has many expressive, powerful abstractions that compile to crazy fast code because the abstractions were well designed. The DOM was not well designed.

    Ten THOUSAND divs in about 200 milliseconds.

    ಠ_ಠ

    There were about 140 items, and it had to be fast on a phone.

    On filter change:

    1. Delete everything.
    2. Render everything from scratch.

    This is pretty much the worst implementation possible

    Quote abridged. No, this is not the worst implementation possible, this is a fast path for the browser. Any modern browser will wait if you are performing basic DOM operations in a tight loop and render them in a batch.

    Why then, do people say that the DOM is slow?

    Because sometimes people do non-trivial stuff, stuff slightly more complicated than rendering a list of 140 things.

    I blame jQuery.

    Of course you do.

    This whole ‘DOM is slow’ is really just “I’m too stupid to know that what I’m doing is stupid”

    No, the DOM is slow due to ancient compatibility constraints that make a lot of stupid stuff impossible to optimize, and you have to just know what those things are. That doesn’t make the DOM fast it makes it finicky and weird and sometimes alright.

    Use document fragments. If you are changing the state of the UI in a loop, don’t change it while that DOM is in the document, because every change you make will cause a re-draw or re-flow.

    Actual solid advice.

    USE THE GODDAMN PROFILER!

    YES! The Chrome profiler can tell you when your code triggering excessive DOM reflows or other DOM stupidity!

    In almost every case, the bottleneck will end up being your code, not the DOM.

    …dammit, the paragraph was going so well.

    1. 10

      TL;DR the DOM renders a static list of plain divs fast, therefore the DOM is fast for all use cases.

      The argument is really that sophisticated, a classic ignorance-revealing rant. No mention of scrolling performance; dynamic performance with complex UIs; performance for path content; low powered devices, etc…

      1. 2

        Could you recommend a more comprehensive evaluation of DOM performance to read?

        1. 1

          Try a bunch of quite different pages on it. Especially those similar to popular sites like top 500 or 1000. Compare time taken to load elements in various configurations. It will tell you more than what’s in the article.

          Hell, maybe even do a Csmith style tool that tests DOM performance with random DOM’s and activity on them.

      2. 3

        Just a few things:

        I wrote this about 3 years ago, and yes, it’s absolutely a rant.

        Animations are still non-trivial to make extremely performant, and there are many caveats, but the core point is that the DOM isn’t slow (creation and mutation of DOM nodes), which it isn’t.

        1. 2

          Actually if you don’t read the whole thing, and just read the TL;DR; it makes more sense.

          PS.: I think that we should collectively stop reading posts with clickbaity titles.