

Velocity.js - tosh
http://julian.com/research/velocity/

======
surreal
Great library. Original discussion (April 2014):
[https://news.ycombinator.com/item?id=7663775](https://news.ycombinator.com/item?id=7663775)

------
netnichols
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?

[1]:
[http://ricostacruz.com/jquery.transit/](http://ricostacruz.com/jquery.transit/)

~~~
cturhan
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.

------
jschrf
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).

~~~
purpleturtle
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-javascr...](http://css-
tricks.com/myth-busting-css-animations-vs-javascript/)

[http://davidwalsh.name/css-js-animation](http://davidwalsh.name/css-js-
animation)

[http://www.sitepoint.com/incredibly-fast-ui-animation-
using-...](http://www.sitepoint.com/incredibly-fast-ui-animation-using-
velocity-js/)

[http://www.smashingmagazine.com/2014/09/04/animating-
without...](http://www.smashingmagazine.com/2014/09/04/animating-without-
jquery/)

[https://developers.google.com/web/fundamentals/look-and-
feel...](https://developers.google.com/web/fundamentals/look-and-
feel/animations/css-vs-javascript?hl=en)

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
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 :)

------
heliodor
Has anyone plugged Velocity into D3 to replace D3's animations while keeping
the rest?

