Update 2017
In response to @Matt Coughlin’s post, browsers that natively support animation, now render CSS and JS animations on their own thread….
CSS-based animations, and Web Animations where supported natively, are typically handled on a thread known as the “compositor thread.” This is different from the browser’s “main thread”, where styling, layout, painting, and JavaScript are executed. This means that if the browser is running some expensive tasks on the main thread, these animations can keep going without being interrupted.
https://developers.google.com/web/fundamentals/design-and-ui/animations/animations-and-performance
This developers doc also supports the currently accepted answer from @user1467267…
Where you can, you should avoid animating properties that trigger layout or paint. For most modern browsers, this means limiting animations to opacity or transform, both of which the browser can highly optimize; it doesn’t matter if the animation is handled by JavaScript or CSS.
The document also suggests implementing the use of the will-change property for the property which you will be animating so that the browser can perform additional optimisations for these properties. In my personal experience, this only seems to be noticeable in chrome for opacity and transform.
element{
will-change: transform, opacity;
}