
Show HN: Velocity.js – Accelerated JavaScript animation - purpleturtle
http://VelocityJS.org
======
jnbiche
It depresses me to no end that even with impressive engineering advances like
this, any modestly graphical intensive app on the browser redlines my dual-
core Intel laptop.

Similar graphics effects in QT or other native technologies not only do not
redline my laptop, _they don 't even raise the core temperature a single
degree_.

I get enthusiastic about cool JS technologies just like most devs, but I feel
like we're moving backwards.

~~~
purpleturtle
I agree. The issue is the DOM. (For contrast, I've seen highly performant 3D
worlds rendered in the browser via WebGL that don't bring my computer to its
knees.)

We've been layering on years of HTML/JS additions that aren't allowed to break
backwards compatibility. (Google's Blink project is one example of an effort
to try to undo some of this.)

------
TeeWEE
Dont forget that CSS based animation is a declarative based animation
framework while Velocity.js is using imperative code to animate (while the
calls look declarative, the code in the framework has to be bundled with your
js).

The advantage of the declarative approach, is that browser can improve the CSS
animations in every browser update. Also, in theory, browsers could improve
CSS animation in such a way that is is always faster than velocity.js.

You could for example make a CSS-animation to velocity.js compiler. Browser do
this compilation (not to velicity.js but to native code/operations) already.
Thats why it surprises me that velocity.js is saying its faster than pure CSS
animations.

Can somebody enlighten me on why this is the case?

~~~
purpleturtle
Yep, I authored an article on CSS vs. JavaScript performance here:
[http://davidwalsh.name/css-js-animation](http://davidwalsh.name/css-js-
animation)

------
nkozyra
Wonderful.

This is one of those things that dogs me as a developer - accepting things _as
they are_. It's something we should all look out for.

If you've ever just tacitly, passively accepted something as potable if not
ideal, you need to develop an internal "Complacency Alert" alarm. I know I do.
For too long I've accepted that you either have to reinvent the wheel with
javascript animations or accept what jQuery has to offer.

Hats off here.

~~~
25cf
> accepting things as they are

really? as opposed to innovating?

~~~
nkozyra
Are you attempting to do a Cliff's notes of my comment?

------
isaacdl
I'm really impressed by the level of documentation in the code[0]. Makes it
fun to read.

[0][https://github.com/julianshapiro/velocity/blob/master/jquery...](https://github.com/julianshapiro/velocity/blob/master/jquery.velocity.js)

~~~
caipre
Well documented sure, but man are there some long lines in there. I get that
80 char width can be a bit limiting, but several of those are 200+.

Still, I'll take the documentation. :)

~~~
dsego
2000 lines of code in one file is too much, should be broken into 4-5 files at
least.

------
slajax
We had Julian come by and demo this to our team a few weeks back. Totally
awesome work he's doing here. Great job Julian.

------
tambourine_man
This blew me away. Never thought JS animations could be faster than CSS.

I'll use it in my next project.

------
nevir
Shouldn't your comparison widget also have a pure CSS option?

Maybe I'm missing something, but I'm not seeing anything to back up the claims
that this is more performant than pure CSS animations?

~~~
purpleturtle
Transit doesn't incur much overhead:
[https://github.com/rstacruz/jquery.transit/blob/master/jquer...](https://github.com/rstacruz/jquery.transit/blob/master/jquery.transit.js)

Either way, there'd need to be some sort of chaining implementation for the
sake of the demo -- and at that point you might as well be using Transit.

As for performance vs. CSS transitions, try out the Performance Comparison #1.
Select Transit as the engine and run it at high element counts. It chokes
pretty quickly. These effects tend to be exacerbated on mobile.

I'll note that Velocity also combines features from jQuery, jQuery UI, and
transitions -- so it's a feature play as well as a performance play.

------
dcsan
how does performance compare with famo.us? they're also css haters, to quote

> “We saw Javascript could do a raw game rendering engine, but we found a way
> to render an app and pass that render to the GPU, skipping all the things
> that we were waiting on the browser companies to fix. We found a way to
> bypass it by having a direct mathematical conversation with the GPU.”

IMHO famo.us seems more oriented toward taking over the whole app and
providing a view-level API, where velocity is more for animating page DOM
elements? For some basic things like delay: the velocity API [1] seems a lot
simpler than the equiv [2] with famo.us, whereas famous has things like a
"Grid" or ScrollView out of the box.

[1]
[http://julian.com/research/velocity/#delay](http://julian.com/research/velocity/#delay)
[2] [http://stackoverflow.com/questions/23330771/how-to-add-a-
del...](http://stackoverflow.com/questions/23330771/how-to-add-a-delay-to-a-
famous-transition)

~~~
purpleturtle
Exactly right -- Velocity is a jQuery plugin and jQuery UI/CSS transitions
replacement whereas Famo.us is a full-fledged app framework built around a
physics engine.

As for a performance comparison, their demos have crashed my phone. So I have
no idea. Looks like they've also pulled their demos link for now:
[http://famo.us](http://famo.us). It's a pretty awesome concept though. I hope
they succeed.

------
voltagex_
Congratulations:

    
    
         	Content Blocked (content_filter_denied)
    
      	Content Category: "Suspicious"
    

Any idea why? (I'm fairly sure my organisation doesn't curate the blocklist,
only purchases it)

~~~
purpleturtle
Thanks for the heads up. Julian.com is currently hosted on GoDaddy -- so
nothing would surprise me :) Switching to AWS later in the week.

------
flockonus
I wonder if other people also see the jitters in this demo when the box is
returning to left? [http://cdpn.io/pLAxF](http://cdpn.io/pLAxF) (click the red
box)

------
daemonk
JQuery should just implement velocty.js' animation functions?

~~~
purpleturtle
I so thoroughly circumvented their CSS and animation codepaths that they would
have to house a lot of redundant code to incorporate Velocity.

But a boy can still dream :-D

------
kylebrown
Can I just get a link to the demo please? There's no reason I should have to
watch a youtube video in order to see a javascript demo.

~~~
Flenser
It's the link right after the link to the youtube video:
[http://julian.com/research/velocity/demo.html](http://julian.com/research/velocity/demo.html)

------
ArtDev
I am definitely going to use it on my next project that needs any animation at
all. Nice work.

------
leo_mck
Should the 3D demo work on IE11? It started fine but then broke, on desktop
and wp8.1.

------
macca321
Any reason you can't just overwrite .animate and have existing code use it?

~~~
purpleturtle
It's generally considered bad practice to overwrite existing functions that
other code relies on -- you can never be sure that your replacement is 100%
compatible.

------
leeoniya
any thoughts on how it compares to the CSS transitions polyfill [1],
speedwise?

[1]
[https://github.com/rstacruz/jquery.transit](https://github.com/rstacruz/jquery.transit)

~~~
purpleturtle
I provide a direct comparison against Transit in the top-right corner of the
documentation.

~~~
leeoniya
ah sorry, missed that. Transit is much smaller though if you dont need all the
features or extremely high perf.

EDIT: looks like Transit introduces hz tearing in perf demo, might be a bug in
lib or demo?

~~~
purpleturtle
Yep, Transit is super small. Velocity still gets quite small though -- about
7Kb when zipped.

As for Transit's tearing and banding at high element counts -- that is indeed
the performance bottleneck of CSS transitions shining through. If you're
interested, you can learn the technical reasons behind Velocity's speed
increase over CSS and jQuery here: [http://davidwalsh.name/css-js-
animation](http://davidwalsh.name/css-js-animation)

~~~
leeoniya
nice. i never understood why jquery never adopted RAF. back compat prolly with
their apis.

------
oe
The playground seems broken (stuck on "Let's play...")

~~~
unklefolk
You need to click on "Let's play..." for it to start.

~~~
rhythmvs
Interesting. I wonder if the ellipsis (…) changes how that wording is being
interpreted by the user. Maybe we’ve been accustomed to the idea that …
indicates an action is being performed by the application (Loading… — We need
to wait.), whereas ! expects us to perform an action (Let’s play! – The app is
waiting.) The UX of punctuation…

------
lightblade
Thanks for proving what I long suspected.

------
itistoday2
Nice, how does this compare with Greensock's performance? Is it better, or
about the same?

~~~
morenoh149
it says in the upper right hand corner. It out performs green sock on higher
workloads.

~~~
bunkat
One of the nice things about green sock is that it doesn't have any
dependencies. That is more important to me than a little bit more performance
(since green sock is already pretty fast).

~~~
purpleturtle
GSAP is awesome. They proved to me that Velocity was a worthwhile pursuit.

------
goldenkey

         "Because transitions aren't natively controlled by JavaScript (they are merely triggered by JavaScript), the browser does not know how to optimize transitions in sync with the JavaScript code that manipulates them."
    

The above voodoo talk is quite a disservice. It's immediately obvious that the
dev does not know how v8 and the dom/CSS/rendering engine are tied together.
The fact that the CSS transition is triggered by JS has no bearing on speed or
optimization.

Secondly, most importantly, JS based fps-style animations eat CPU, and battery
power of portable devices. On the other hand, CSS transitions are only getting
better. Most CSS transitions are GPU optimized and light on CPU usage. A web
page should not be strangling the v8 engine for graphical animation that could
instead be GPU-bound. This library is clever but a step in the wrong
direction. The dev could have contributed to WebKit CSS key frame animation
acceleration instead.

Thirdly, JS animations cannot handle the sheer amount of particles that CSS
transitions can. For instance, take Ana Tudors box-shadow particle hack, and
look at how performing it is through GPU acceleration.

[http://codepen.io/thebabydino/pen/shtGe](http://codepen.io/thebabydino/pen/shtGe)

~~~
purpleturtle
You misread my quote entirely.

If you read further down the article you're referencing (davidwalsh.name/css-
js-animation), you'll see an example of how Velocity caches values between
consecutively chained calls. THAT is an example of the browser not knowing
when to optimize transitions in sync with JS code. Another example from that
same article: Caching unit conversion ratios (e.g. px to %, em, etc.) across
sibling elements in the same call.

Further, JS animation does not eat up mobile devices. You're conflating
concepts.

I know that HN can be a stomping grounds, but there's no need to be rude.

~~~
goldenkey
Caching values is an obvious and necessary optimization.

The claim that the CSS transition cannot know when the property changes due to
JS, therefore cannot optimize, is total fluffery. The main loop is render, JS,
and never at the same time. That is why a JS loop will freeze the browser.
Have you no idea that it's all single threaded?

