Hacker News new | ask | show | jobs
by ghayes 4352 days ago
If this technique is much more performant (batching diffs of the DOM), why don't browsers perform this "back-buffering" natively?
3 comments

They do perform this "back-buffering" natively. When you manipulate the DOM in a modern (post-2009 or so) browser, it's just changing a pointer and flipping a dirty bit.

The problem is that it's very easy to force a full recalculate of the whole page layout. Whenever you call .offsetHeight or .offsetWidth or .getComputedStyle, you're doing it. The full list of properties is about 2 dozen strong:

http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-...

Most web developers don't know this, and so they're actively making their pages slow. Worse, many popular frameworks build this into the library, and so if you use them, there is no way to keep your pages responsive. JQuery, for example, can easily cause 4-5 layouts with a single call to .css; on a mobile phone and a moderately complex page, that's about a second of CPU time.

This got me wondering how React handles this requirement. Can you use React if you need to know offsetWidth/Height to do complex layout?
Once the component is mounted (there's a componentDidMount callback) you have access to the real DOM node and can access them (or perhaps store them as a property if necessary). The DOM node is also available from event callbacks and such.
Not everything needs to be built-in. There are significant trade-offs for baking things into the browser, and it's actually far better to keep things as libraries. You don't have to worry as much about backwards compatibility, it's far easier to roll out updates, etc.

Also, the fact is that the web is stuck in a Web Components-driven approach to building apps which is pretty orthogonal to how this works.

They try their best, but often naive code will make changes and then read values in an order that requires recalculation to produce the right value.