4 ms·

I remember hearing in a presentation by Douglas Crockford that the browser will reflow only after the event that triggered the JS has been handled. So if you d

by rix0r 16y ago

I remember hearing in a presentation by Douglas Crockford that the browser will reflow only after the event that triggered the JS has been handled. So if you do 1 insert or 1000 in response to an event, it should only cause 1 reflow. Animation on the other hand...

jasonkester 16y ago
No other hand required for Animation. It works the same. Any changes you make to the DOM/CSS are rolled up and happen together. Even changes to position, CSS transforms, etc. That's why your effects code ends up having all those setTimeout(function(){keepGoing()}, 0); blocks in it. You need to chill from time to time and let the browser render what you've done already.
dspillett 16y ago
Correct with most (all?) browsers. Though the code presented would still be faster ignoring the reflow issue because is is calling document.getElementById("content") in every iteration of the loop where the optimised version calls this only once. Of course yuo could cache the reference to the element to avoid the repeated getElementById calls but affecting the DOM via the innerHTML property on each loop is still going to be at least marginally quicker than affecting a local string variable. This is all beside the point though: that example is for a specific part of their API. Keeping the example short by not adding more lines in order to optimise an unrelated area makes it a better example in the intended context even if not a complete show of general coding "best practise". The original link's "better" option is bad for its own reason: it misses the glaring opportunity for reference caching. If you are going to call one example bad because of a missed optimisation make sure your counter example does miss an even more obvious one!
- dspillett 16y ago
  Please ignore the above post - I seem to have completely misread a chunk of the linked article so my point about reference caching is completely and utterly wrong (the document object's search method is only called once in the counter example). Remember kids: think before you post.

by rix0r 16y ago

jasonkester 16y ago

No other hand required for Animation. It works the same. Any changes you make to the DOM/CSS are rolled up and happen together. Even changes to position, CSS transforms, etc. That's why your effects code ends up having all those setTimeout(function(){keepGoing()}, 0); blocks in it. You need to chill from time to time and let the browser render what you've done already.

dspillett 16y ago

Correct with most (all?) browsers. Though the code presented would still be faster ignoring the reflow issue because is is calling document.getElementById("content") in every iteration of the loop where the optimised version calls this only once. Of course yuo could cache the reference to the element to avoid the repeated getElementById calls but affecting the DOM via the innerHTML property on each loop is still going to be at least marginally quicker than affecting a local string variable. This is all beside the point though: that example is for a specific part of their API. Keeping the example short by not adding more lines in order to optimise an unrelated area makes it a better example in the intended context even if not a complete show of general coding "best practise". The original link's "better" option is bad for its own reason: it misses the glaring opportunity for reference caching. If you are going to call one example bad because of a missed optimisation make sure your counter example does miss an even more obvious one!

dspillett 16y ago
Please ignore the above post - I seem to have completely misread a chunk of the linked article so my point about reference caching is completely and utterly wrong (the document object's search method is only called once in the counter example). Remember kids: think before you post.