If the DOM is a data base, then transactions are the missing feature. React adds this. One react cycle is like one transaction. If the browsers would support a kind of native DOM transaction, there would be less hype around React.
The existing "batch operation" in DOM is setInnerHtml. It's funny that this is sometimes faster to set the html string on some top element than changing 100 of little child DOM nodes. Apparently the browser is really good in parsing HTML snippets (no wonder). Imagine how fast things could be, if we could tell the internal browser API more directly which little nodes changes. DOM transactions will come.
There is already a proposal from 2012 about DOM transactions, here as a special use case for undoing changes when implementing editors.
There also is a reasonably well-starred library for DOM batch operations on GitHub, called fastdom. But all it seems to do is group DOM manipulations to occur en groupe. I could not understand how this is much faster, because event processing still happens after every step in the update. Real DOM transactions will group all event processing together, too. Also, like in React, changes that cancel each other out will just not result in any events.
According to this test, manipulating DOM nodes is really not much faster per se. But changing 100 of different nodes, which have event handlers attached, does make the difference. Thats at least the whole reason for Reacts virtual DOM.
Outlook:
I'm not sure, if clever use of Shadow DOM or other web component technologies can be used as DOM transactions.
No comments:
Post a Comment