In addition to what the other replies said, there's another reason: effects like this reside purely in the presentation layer, and just like the argument for se

In addition to what the other replies said, there's another reason: effects like this reside purely in the presentation layer, and just like the argument for separating content from presentation, a good argument can be made for trying to separate application code from presentation as much as possible. The less animation you're doing with JavaScript, the less your application code will have worry about updating the presentation layer in a loosely coupled way – just changing a CSS class or whatever already provides that (relatively) loose coupling. At BigDoor, we ship the same JavaScript code to many different partners, but their widgets can have very different form factors and visual effects. It's nice to not have to distribute a bunch of animation code to every partner just in case one partner's theme happens to use it – we can keep it in the CSS and just swap that out. Soon I think people will see that using JavaScript for the simple animations they've been performing all this time (fade out, slide in, etc.) is just creating a tightly coupled system.