...or more specifically, how are they able to create animations via javascript, which is synchronous, without holding up the next javascript statement.
It's just a curiosity. Are they using a chain of setTimeout()? If so, are they set early, each one with a slightly longer duration than the previous, and running parallel? Or are they being created through a recursive function call, therefore running in series?
Or is it something completely different?
There is an alternative to setTimeout() called setInterval() which will call the function you pass as argument at regular intervals. Calling setInterval will return a value which can be passed to clearInterval to stop the function from being called.
With jQuery 1.4.2 on lines 5534 - 5536:
if ( t() && jQuery.timers.push(t) && !timerId ) {
timerId = setInterval(jQuery.fx.tick, 13);
}
Notice the setInterval for jQuery's tick method that triggers a step in an animation.
Chained calls to setTimeout aren't really "recursive". If one setTimeout function, when called, sets up another timeout with itself as the handler, the original invocation will be long gone by the time the new timeout occurs.
Using setTimeout instead of setInterval is (to me) often more flexible because it lets the timed code adapt (and possibly cancel) itself. The general pattern is to set up a closure around the setTimout call so that the data needed by the timed process (the animation, if that's what you're doing) is available and isolated from the rest of the app. Then the timeout is launched on its initial run.
Inside the timeout handler, "arguments.callee" can be used for it to refer to itself and reset the timeout for subsequent "frames."