> DOM mutations are not the expensive thing, it's the final render.
This is the crux of the issue: Updating the DOM will immediately rerender the page, even if there are additional changes that need to be made at the same time. So library/framework authors twist themselves into pretzels trying to work around the browser automatically doing all this unnecessary extra work that developers don't even want. Clearly it's a DOM api deficiency; there is no api to 'make these 15 changes scattered across the DOM all at once', instead each individual change causes a cascade of wasted effort repeated until the last change is applied OR developers take the nuclear option and just replace the whole damn page with a completely new DOM on every frame. Insanity. The solution seems obvious to me:
Browsers should introduce a transactional DOM api that is only rendered after the transaction is 'committed'. It could be full-on transactions like a real DB or something simpler like a double-buffered frame swap. This would be relatively easy to retrofit into JS apps and frameworks and would enable them to effortlessly avoid a huge amount of wasted effort on the part of the browser.
> DOM mutations are not the expensive thing, it's the final render.
This is the crux of the issue: Updating the DOM will immediately rerender the page, even if there are additional changes that need to be made at the same time. So library/framework authors twist themselves into pretzels trying to work around the browser automatically doing all this unnecessary extra work that developers don't even want. Clearly it's a DOM api deficiency; there is no api to 'make these 15 changes scattered across the DOM all at once', instead each individual change causes a cascade of wasted effort repeated until the last change is applied OR developers take the nuclear option and just replace the whole damn page with a completely new DOM on every frame. Insanity. The solution seems obvious to me:
Browsers should introduce a transactional DOM api that is only rendered after the transaction is 'committed'. It could be full-on transactions like a real DB or something simpler like a double-buffered frame swap. This would be relatively easy to retrofit into JS apps and frameworks and would enable them to effortlessly avoid a huge amount of wasted effort on the part of the browser.