Currently I’m experimenting with jQuery (always being told prototype.js is evil). In my project I have to make quite some complex animations and I tried to detect if I can map them to the animate() syntax. Uh, and all hell broke loose. Here is my 24h experience:

1. You can’t animate regular DOM properties, like image width/height, which is much more smooth than styles.
2. It does not hold custom states, nor allows you to animate a virtual property ‘counter’ out of that you could folk all kinds of changes in the step-function. You HAVE TO animate a real css-style. Thus you fall back to your own timers and loose the easing-framework. Found it. But not optimal …
   
3. You can not hold any states, if you stop an animation you will loose the information about the position of the animation between [0.0,1.0], and any other. You have to track that via the step-function and calculation through the ‘now’ time-stamp, OR you calculate the position directly on the modified CSS-value.
4. Each modified style enters the effects-queue as a seperate function, or expressed differently: each property given to animate to change becomes an entire seperate animation!
5. animate’s step function is called per step per property! Simultanious animation of multiple values becomes together with 4) almost impossible! A simple zoom function (width+height on content, left+top on parent relative to childs size-change) requires you to write approx. 50 lines!
6. You can’t pause/resume animations (no states), you have to recalculate the position (see 3), recalculate how much time is missing and restart the animation.
7. width/height animations force overflow hidden and display block. In 2010 I’d like to animate overflow visible and display inline-block too! Maybe even tables-cols if you don’t mind …
8. You can’t define proxy-animations like “font-size = height / 10″, normally I’d say it should be possible to reference any animateable attribute/style.
9. You can’t because of that also forget about the “font-size += delta-height” type.
10. All calculations are done in floating point, as no browser supports sub-pixel accuracy you’l have horrible shift while zooming an image for example. The “zoom” effect anyway should be integral part of animate. Either way [left,left+width] are on a pixel-precision grid, if left becomes round down, left+width has to be round up (for zooming that is), of course trying to acount for this leads to headbanging on the keybord, because the animations are all seperate … and the step function is called per property …

Grr. Such a small function and so much issues.