Show HN: Velocity.js – Accelerated JavaScript animation
velocityjs.org
velocityjs.org
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.
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.)
On a related note, if you create your whole app in WebGL, you then lose all the benefits that HTML/JS/CSS brings, like simple user input.
Finally, WebGL is not even available to the general public yet. As far as I know, it's still behind feature flags on almost all browsers.
Have any major browsers removed the WebGL feature flag? If so, it's very recent.
WebGL is very cool, but it's still depressing that web devs have to program in GL to get decent graphics performance.
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?
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.
really? as opposed to innovating?
[0]https://github.com/julianshapiro/velocity/blob/master/jquery...
Still, I'll take the documentation. :)
I'll use it in my next project.
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?
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.
> “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 [2] http://stackoverflow.com/questions/23330771/how-to-add-a-del...
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. It's a pretty awesome concept though. I hope they succeed.
They (Famo.us) cannot hate CSS too much because they use CSS transforms to do their animations.
http://www.infoworld.com/t/web-applications/fast-and-flashy-...
Content Blocked (content_filter_denied)
Content Category: "Suspicious"
But a boy can still dream :-D
EDIT: looks like Transit introduces hz tearing in perf demo, might be a bug in lib or demo?
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
"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."
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.
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.
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?
I haven't delved deeply into all the tradeoffs - maybe it will overuse the CPU - but there's definitely something going on here.
There's a similar library called GSAP (http://www.greensock.com/gsap-js/) and they've made similar points (http://css-tricks.com/myth-busting-css-animations-vs-javascr...).