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.
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!
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.)
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.
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?
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.
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.
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.
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.
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
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…
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).
"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.
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.