I did this same experiment with D3 (animating the outline-color and background-color for 1s with ease-in-out), and I got performance nearly identical to CSS.

http://bl.ocks.org/d/1616423/

A lot of this gain is likely from using requestAnimationFrame, but there could be other optimizations in D3, such as a single timer loop for all transitions. So, I think it's misleading to say you can't do fast transitions in JavaScript. It might just be a need to optimize jQuery.

But still, I definitely prefer to use CSS transitions when possible, because the performance is generally better and I like the declarative syntax.

Raphael also suffers when animating many elements, here is a question I answered about a week ago on StackOverflow and I ended up solving with d3.js:

http://stackoverflow.com/questions/8239235/smoothly-animate-...

But recently I went through Raphael's source an I saw an implementation on requestAnimationFrame, perhaps Mike can shed some light on what is different. Great work on d3.js by the way!

That is much better than the jQuery version - particularly the use of requestAnimationFrame. It still has almost a second of Recalculate Style before the animation, but the animation at least manages to get some frames in.

I'm hoping that if nothing else this post prompts the jQuery team to have a look at their animation function.

Why is everyone missing this? JQuery is a library that provides a consistent API across browsers. In a future release couldn't they detect CSS3 animation support and update the animate function to use them if supported?

Some projects are already doing this:

http://www.benbarnett.net/2010/09/01/enhancing-jquerys-anima...

Sounds like it should go into mainline jquery pretty soon.

Exactly - hopefully this will happen one day. Having used that plugin though it doesn't work perfectly on all code (jQuery Cycle + that for instance doesn't always work as expected). Any mention of transitions seems to result in a wontfix if you check through the jQuery bug tracker.

I suspect what is holding it up is both browser support and the time required to get it right. Maybe they don't use animate but provide a separate wrapper.

Keep in mind, the specs are rather large. When people talk about CSS "animations" there really talking about at least 3 specs, maybe 4. CSS 2D transforms, CSS 3D transforms, CSS transitions and CSS animation. There is a lot of work to get it right and tested in a nice JS wrapper, not to mention making it work with an existing JS based API.

Sure, native tweening is fast and great, but don't show it by performing a false comparison.

The CSS transition is performing a single tween on a CSS rule; the div tags just inherit the result. The jQuery test is performing inline style tweens ... on every div! First of all you're performing redundant/duplicate calculations. Second of all, you're throwing away all performance gains you had by having shared css render style objects.

A better test would of been to update the style sheet via JS.

Not a very good example. For me the CSS3 version isn't smooth either (in chrome). And generally the transition should be more eye-catching to make your point.

I'm in chrome on an air, and the difference is very clear. Probably hard to come up with something that'll work for everyone...if he exaggerates it too much, it'll risk blowing up phones!

I'd like to see a comparison between CSS3 and html5 canvas performance, as for a simple animation in this example, I think Canvas may be more applicable.

The difficulty with canvas is that it can't really be dropped in to a site in the same way. A site that makes use of slides and fades using a JS library could patch the library to use transitions instead with only a few lines of code (well a few hundred perhaps). Using canvas requires dropping the accessibility benefits as well as having to replicate all the elements manually on canvas.

I agree though, this contrived example would surely work better with canvas.

I actually want to know more about SVG than canvas. Since SVG already has the concept of translate, scale, ect... built in, are these hardware accelerated like CSS3 animations for DOM nodes?

agreed, canvas will probably perform better because it is made for animations where as DOM was not made with animation in mind. Plus canvas animations are, in some cases, hardware accelerated i believe?

In FireFox the problems are either with the timer or how fast a screen is drawn.

On an old laptop, changing the opacity, or set a different color of the same amount of divs takes about 50ms. The next timeout or interrupt, is on average 200ms later. The first screen draw is the slowest with 350ms.

I used absolute position for the divs, so that the browser doesn't have to recalculate the page after each update.

Also, I'd really appreciate some help in explaining the discrepancy here. I've had a go at the bottom of the page, but if anyone has any input I'd be keen to get it as correct as possible.

Agreed, the analysis doesn't make things too clear. If you look at the code, all the CSS element does is add a class to the containing div. The jquery version has to animate each square.

From his explanation, browsers are smart enough to not only batch (how I'm thinking of it) css animations to all elements, but they also know what part of the screen will change and only have to redraw that.

The jQuery one just spends too much resources changing the properties of all those boxes to have any time to actually redraw the screen.

The selector is applied to all the boxes, not just the outside one. The point here is that jQuery doesn't work well for doing lots at once really.

maybe i am not getting something here but isn't this obvious? native c++ will be faster than javascript (which also compiles to c++ (i believe?) but does not have hardware acceleration and is single threaded [in case of jquery atleast]). Libraries (like jquery) were made to fill in the gaps that css or js had. now that the gaps are filling up, jquery becomes a redundancy (atleast for basic animations like that of css) So what is the need for testing? or maybe i am missing something?

This is part of a tutorial, the idea was to give some evidence for justifying the use of transitions where possible.

It also might get more people to realise that jQuery isn't the answer to everything, and animation is definitely not one of it's strong points (right now anyway!)

Yes, i see it now, there seems to be some confusion as to the need of the article. It makes more sense in a tutorial perspective and is needed to pull people off of jquery. Thanks for clarification. :)

So why doesn't jQuery help me be smart and do CSS transitions where available? Or would it be to difficult to translate my JavaScript animation instructions to CSS animations?

My apologies if I come across the wrong way, but this doesn't take an article to explain.

CSS3 transitions and keyframes are hardware accelerated and in most cases native to the browser.

Doing anything with javascript and the DOM is single threaded and expensive.

If you are using jQuery, look at cssHooks for nice fallbacks to js animations if you feature detect for particular effects.

I agree - this is part of a tutorial, and these examples are really to prove this point.

Animations using javascript were great when we didn't have anything else, but nowadays they should only be used in browsers without support.

What would be really cool would be a DOM method that tied into the animation code that powers transitions.