Hacker News Reader

Comment by CharlesW | Hacker News Reader

> That way, you only do the IDL-dance once and the browser then manipulates the tree in C++ with the many operations you fed it.

As a beginning web developer, I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions, or even an equivalent to HyperCard's lockScreen.

I'm finding it a little tough to tell whether the author is talking about putting the browser or the web developer in control of grouping DOM updates.

View on HN

> [...] I remember being surprised that there was no way for me to group DOM manipulations into SQL-like transactions [...]

There is a way to group DOM manipulations: a DocumentFragment[0]. If you have a wrapper, you can easily use

    parent.replaceChild(fragment, wrapper); // [1]

So long as you start with your fragment having a new copy of that wrapper—the entire node and its children will be replaced in 1 operation. Then layout and paint should only happen once apiece.

I've used similar techniques to make applications that render efficiently.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra... [1]: https://developer.mozilla.org/en-US/docs/Web/API/Node/replac...

That assumes that all the changes are grouped under the same part of the tree...

Sure. If you have a ton of potentially layout-thrashing changes, just clone your page's highest wrapper node. Then make your changes and replace the node. I haven't needed it, or tested it for performance, but it's clearly doable.

    // Example; untested pseudo-code
    var fragment = document.createDocumentFragment(),
        wrapper  = document.getElementById('wrapper');
    
    fragment.appendChild(wrapper.cloneNode(true));
    // update your fragment
    // update the page
    document.body.replaceChild(fragment, wrapper);

That said, because the change is to a page's entire structure I'd think the layout operation would be much slower. I'm betting React and Ember might do similar things for their "application" wrapper/scope node(s).

You also potentially lose things like focus, input text, and selection on elements that otherwise didn't need to be replaced. I'd wager that re-creating all of that would add a discernible performance cost.

The more I learn about HyperCard, the more amazed I am about how nifty piece of technology it was. Too bad I haven't been fortunate enough to ever use it.

http://www.jaedworks.com/hypercard/HT-Masters/visual-effects...

You actually can, via (ab)using requestAnimationFrame. It's been a while since I did front-end development, but back in the day (...okay, 2014 ish) we'd batch DOM reads and writes, run through them the next time the frame was painted, and avoid multiple redraws. It was rather cumbersome, especially since reads had to be asynchronous, but it was fast.

I'm a big fan of the Mithril MVC framework, it does some pretty smart autoredrawing [0] while still allowing you manual control of when things are drawn if needed [1]

[0]: http://mithril.js.org/auto-redrawing.html

[1]: http://mithril.js.org/mithril.redraw.html

fastdom might be of interest – it batches read and write operations into separate queues and runs them using requestAnimationFrame:

https://github.com/wilsonpage/fastdom

> I'm finding it a little tough to tell whether the author is talking about putting the browser or the web developer in control of grouping DOM updates.

The Web developer (or library author). He is talking about an API.

Reply on news.ycombinator.com