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
"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.
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.
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?
Theoretical objections aside, I have seen preview demos of Velocity on mobile devices, and it is surprisingly quick compared to its competitors. Even with demos involving many, many, particles.
I haven't delved deeply into all the tradeoffs - maybe it will overuse the CPU - but there's definitely something going on here.
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.
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.
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.)
How can you not get excited about this? It's 2014 and we've finally gained the technology to animate one hundred and fifty moving dots on the screen! At the same time!
It's because both jQuery and Velocity suck at animation. DOM is not designed for fast animation. Use the right tools, like WebGL, and your can have thousands of sprites animated simultaneously at 60fps.
The thing is, a web developer will almost never really need graphics intensive stuff that would see a huge performance boost from WebGL. It is definitely a problem, but it is just nowhere near as big of an issue as things like javascript + dom standards compliance.
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).
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.
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.
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. It's a pretty awesome concept though. I hope they succeed.
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…
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?
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.
51 comments
[ 4.4 ms ] story [ 90.7 ms ] thread[1] https://github.com/rstacruz/jquery.transit
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
But a boy can still dream :-D
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
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...).
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.
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.
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. :)
> “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-...
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?