Funnily enough I was just today checking out Transit[1] for a project I'm working on. Has anyone gone through the process of picking Velocity vs. Transit? What made you pick one or the other?
author of Transit here. Velocity actually has a comparison over in its page (top right area) that makes velocity a good choice for animating multiple elements at once.
I used jquery.transit for some of my project. I liked it a lot. As it is very simple to use (it's more like jquery.animate) you can easily animate even without looking at source code. If you need some simple animations like page transitioning, side menu opening I think jquery.transit is ideal. However, if you need some complex transitions like chaining and animating properties in different easings, I suggest you to try Transit.
Edit:I'm not sure if it's fixed now but there was the problem when I was using. When you start animation and then you want to stop it because user clicks another button etc, it doesn't stop properly. It breaks animation without pausing.
I was using Transit, which performed very well. After pulling in HighchartsJS I ran into a strange conflict (tbd) in the transitions (animations), so just switched to Velocity. Works well.
I recently looked into using Velocity on a mobile application. I need simple animations but they need to be performant.
I was dismayed to find that Velocity and almost every other animation library out there still uses DOM-based tweening rather than CSS transitions.
Even some of the faster libs out there that leverage CSS transforms are still pushing frames manually and sucking up CPU cycles running code-based animations.
Why are people so convinced that code-based animations are somehow faster or better than pure CSS transitions?
I certainly understand and appreciate the flexibility of code-based animations (easy chaining, full control, older browser support etc.), but for simple things like panels sliding in and out of view, nothing beats transform3d and transitions on platforms when these things are available (which is most mobile devices, these days).
Choose the right tool for the job. Sure, for simple things, CSS transitions are likely the right tool. For more complex animations where you need more control over them, frameworks like these are invaluable.
Fear not. Your performance concerns are mostly unwarranted (creator or Velocity here). Here are some articles to consider reading that help debunk this myth:
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.
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 :)
10 comments
[ 3.2 ms ] story [ 31.2 ms ] thread[1]: http://ricostacruz.com/jquery.transit/
Edit:I'm not sure if it's fixed now but there was the problem when I was using. When you start animation and then you want to stop it because user clicks another button etc, it doesn't stop properly. It breaks animation without pausing.
I was dismayed to find that Velocity and almost every other animation library out there still uses DOM-based tweening rather than CSS transitions.
Even some of the faster libs out there that leverage CSS transforms are still pushing frames manually and sucking up CPU cycles running code-based animations.
Why are people so convinced that code-based animations are somehow faster or better than pure CSS transitions?
I certainly understand and appreciate the flexibility of code-based animations (easy chaining, full control, older browser support etc.), but for simple things like panels sliding in and out of view, nothing beats transform3d and transitions on platforms when these things are available (which is most mobile devices, these days).
http://davidwalsh.name/css-js-animation
and this one (about GSAP, not Velocity)
http://css-tricks.com/myth-busting-css-animations-vs-javascr...
Choose the right tool for the job. Sure, for simple things, CSS transitions are likely the right tool. For more complex animations where you need more control over them, frameworks like these are invaluable.
http://css-tricks.com/myth-busting-css-animations-vs-javascr...
http://davidwalsh.name/css-js-animation
http://www.sitepoint.com/incredibly-fast-ui-animation-using-...
http://www.smashingmagazine.com/2014/09/04/animating-without...
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.
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 :)