I didn't go in with any assumptions. There's been lots of advice given that using transform:translate() is always the fastest path; the point of this was to measure and see. Also knowing something is faster isn't the same as knowing how much faster. This can have implications when deciding what technology and tradeoffs to use.
Besides, is it really obvious that top/left would be faster (in a non-transition case)? It requires an additional layout phase compared to transforms:translate().
On the common sense of transitions being faster, it is true that there will be overhead in running JavaScript code. But at the same time, 1/60th of a second is a very long time for a computer and (for me) the overhead of crossing the bridge and running a minimal amount of JavaScript was an unknown.
Being from the "show me state" I like to measure before doing any performance optimization work or making general claims.
Cool, thanks. I understand better now what you were saying in the blog post because I read it a few more times after I wrote that comment.
Also, I think you may be surprised how much overhead crossing the bridge from js to native incurs. It's pretty negligible in most cases, but for things like animation it can be a killer.
Besides, is it really obvious that top/left would be faster (in a non-transition case)? It requires an additional layout phase compared to transforms:translate().
On the common sense of transitions being faster, it is true that there will be overhead in running JavaScript code. But at the same time, 1/60th of a second is a very long time for a computer and (for me) the overhead of crossing the bridge and running a minimal amount of JavaScript was an unknown.
Being from the "show me state" I like to measure before doing any performance optimization work or making general claims.