A handful of comments on an otherwise fairly reasonable article.

> When we run into jank like this as developers, the usual reaction is to wonder “is my code slow?” and start picking apart algorithms or looking for wasted computation. In most cases, though, the speed of the code is not the problem. The code isn’t slow. It just happens to be the code that’s holding the main thread.

Eh, most of the time it is slow, because you chose to use React. React used naively scales very badly. You have to jump through lots of sometimes-fiery hoops to make React… not much slower than some of the alternatives. Memoisation (possibly now via React Compiler) and things like that.

> [Diagram with rAF, Style, Layout and Paint attributed to the main thread]

Paint hasn’t been on the main thread in Firefox since 2017: https://mozillagfx.wordpress.com/2017/12/05/off-main-thread-...

Not sure about other browsers. Firefox has generally been the leader in these areas.

> [steering cost demo]

The demo is deeply unsatisfying because the simulations are quite different in a very problematic way: in “all at once” mode, it loses most mouse movements, which radically affects the simulation which is attuned to movement events rather than simulating physics based on a constant tick rate. Without examining it closely, my guess is it’s using pointer events and the browser is coalescing the events because of the blockage and it’s only taking the final state rather than going through all of getCoalescedEvents(). In a simulation like that, if you can’t run it at full speed, you have to decide what to do, and you should do it deliberately, because it may be disastrously wrong. Should you fall over, simplify the simulation by dropping some of the calculations, reduce the tick rate, something else?

> The demo below is a markdown editor with a long CHANGELOG open. Building the preview means parsing the entire document (about 2,000 lines) and rebuilding its DOM from scratch, which is far too expensive to run on every keystroke.

No it doesn’t. This is a clear example of your code being slow, because you’re doing the wrong thing. You want an incremental parser of some kind. Markdown is tolerably well-suited to this kind of thing because for most edits you can just render the current paragraph.

The suggestion is bad. “Debounce 300ms” behaviour is obviously worse for small documents.

> DOM writes can be batched as well. Appending a hundred nodes in one operation instead of one at a time, or toggling a single class instead of changing style properties individually, turns many changes into one and helps performance. The old technique of assembling an HTML string and assigning it to innerHTML in one shot has the same essence. You gather the writes so the rendering pipeline’s fixed cost is paid once.

This is simplified far beyond accuracy. parent.append(one_hundred_nodes) and one_hundred_nodes.forEach(node => parent.appendChild(node)) are unlikely to perform particularly differently. Changing style properties individually isn’t that* much worse than toggling a single class (it amounts to rewriting the style attribute a bunch of times, and the CSS parser and serialiser aren’t particularly slow). Building an HTML string and assigning it to innerHTML is better than constructing children manually in some cases, worse in others. The real thing that matters is avoiding triggering layout unnecessarily by things like accessing clientWidth between changes.

> Deferring

The lazy rendering trick used here is very problematic because you still need to know how tall each item is. Plenty has been written about hazards of infinite scrolling, that’s what’s being dealt with here. Now if you can have each item be a fixed height, then progressive rendering has far fewer side-effects. I would also say that switching from Notifications back to Feed and having it take an extra few hundred milliseconds is really not that bad. And that I’m not convinced the approach taken was right anyway, you could often just leave the feed rendered and avoid affecting the gross layout.

—⁂—

On the presentation of the site itself: this makes no sense:

  .post-content ul {
    word-break: break-all;
  }

The browser's main thread is expensive