4 ms·

Fear not. Your performance concerns are mostly unwarranted (creator or Velocity here). Here are some articles to consider reading that help debunk this myth: h

Fear not. Your performance concerns are mostly unwarranted (creator or Velocity here). Here are some articles to consider reading that help debunk this myth: http://css-tricks.com/myth-busting-css-animations-vs-javascript/ http://css-tricks.com/myth-busting-css-animations-vs-javascr... http://davidwalsh.name/css-js-animation http://davidwalsh.name/css-js-animation http://www.sitepoint.com/incredibly-fast-ui-animation-using-velocity-js/ http://www.sitepoint.com/incredibly-fast-ui-animation-using-... http://www.smashingmagazine.com/2014/09/04/animating-without-jquery/ http://www.smashingmagazine.com/2014/09/04/animating-without... https://developers.google.com/web/fundamentals/look-and-feel/animations/css-vs-javascript?hl=en https://developers.google.com/web/fundamentals/look-and-feel... For what it's worth, Velocity is a fairly new library. I wouldn't have gone down the path of JavaScript-based animation had my research and testing demonstrated that it was appreciably inferior in any way.

jschrf 12y ago
Hey, thanks for the links. Also, nice job on Velocity. I'm still unconvinced that tweening is the way to go in most animation use cases (basic combinations of slides, fades, etc) The bottom line is this: Most animation libraries write to the DOM every "frame". That's bad. If you need complex timing control, nested timelines, hierarchical animations, etc. then a code-based solution will get you those things. However, they come at a cost and that cost is performance. I think that if you can represent an animation in pure CSS, it will always be faster than implementing it in code, but I'm happy to be proven wrong :)