There are many conversations between designers and engineers that go back and forth about the performance of animations in JavaScript. Often there is an expectation of animations to run consistently (same speed, same step size, same in all browsers, etc.), and as awesome as that would be, this pushes at the limitations of JavaScript.

Many designers experience a great working animation on a demo page, and in turn, expect that the animation can be plugged into a complex JavaScript library, whilst preserving its performance.

Again, as wonderful as this would be, there are a few things that need further explanation. Todays article will look at a simple animation in 3 top libraries: YUI, jQuery, and Prototype/Scriptaculous; and show how uniformly all the animations work well on a simple page, but degrade as the page becomes busier.

Many of you probably know that there are a number of issues affecting how well an animation works in JavaScript: how busy the client machine is, how much CPU/memory your browser dedicates to JavaScript, how much JavaScript is needed to run a given page, and how much work the JavaScript is already doing; to name a few. Also, animation libraries use a combination of the setTimeout or setInterval methods of JavaScript, which are notoriously inaccurate (+/- 15ms), and/or (new Date()).milliseconds() to attempt to smooth animation, but it is fairly easy for an entire step in the animation to be skipped. The summary is that the more complex a page gets the less consistent that animations become.

I choose to compare these three libraries because: YUI is my library of choice, as it was designed by engineers for engineers; Prototype/Scriptaculous is probably the most used library (thanks to ruby on rails and cakePHP); and jQuery is the most popular designer-used library. However, I expect that GWT, Mootools, Dojo, Mochikit, and all the others to behave about the same.

---

For this experiment we are building 3 animations that increase the width of an element from 100px to 400px, and then the reverse, using each library independently. Fortunately, both YUI and jQuery use self-contained namespaces, so they dont conflict with Prototype. Here is the code required for each:

All implementations use a click event callback on a button to trigger animating. There is a global globalDuration variable that can be adjusted on the demo page; YUI and Prototype/Scriptaculous use seconds, while jQuery uses milliseconds. The callback function first checks to ensure that we are not already animating, which is done by setting a boolean via a callback for Prototype/Scriptaculous and jQuery, and calling the isAnimated method on the Anim object in YUI. Then we use a isOpened boolean to determine whether to animate in or out. In Prototype/Scriptaculous and jQuery we call 1-off methods that runs the animation, whereas in YUI we create Anim objects and call the animate methods.

What I Learned

I still don&rsquot;t like Prototype/Scriptaculous. It took me forever to get the animation working (hours, compared to minutes with the other libraries). *Thanks to Artyom prototype is now working correctly.

Prototype/Scriptaculous and jQuery use a linear progression by default, while YUI uses uniform steps by default.

All 3 libraries have a variety of easing methods to accelerate/decelerate the step size

They all work great under no-load, and fairly well under load. They occasionally glitch, but tend to be rather minor.

Matt Sweeney, of YUI, has provided a sinoidal easing method for us, so that YUI animates about the same as the other libraries.

I was just sitting down to write an article about the differences between the Event handlers of Prototype versus YUI, and many of the other Frameworks, when I stumbled upon the new release candidate (version 1.6) of Prototype. I have to say that I am surprised and impressed. A lot I planned to discuss has changed and it seemed more appropriate to highlight the important changes found in the next release. http://www.prototypejs.org/2007/8/15/prototype-1-6-0-release-candidate Here ...

5 JavaScript Frameworks

I stumbled upon this article today, while researching techniques for capturing the back button in JavaScript. This article highlights the features of 5 top-tier JavaScript frameworks:

YUI

Prototype

Rico

Qooxdoo

Dojo

Justin, says Top 5, but doesnt say what criteria he measured them by. Ignoring his ranking, these are 5 powerful Frameworks (although Rico is really an extension of the Prototype Framework). And I had not taken a look at ...

I saw this post on one of my favorite blogs, Agile Ajax. Despite the title, it is not an analysis of jQuery versus Prototype but a discussion of the OOP design of the two Frameworks. I like Brians analogy of Prototype being JavaScript with training wheels and other Frameworks like programming without training wheels. Using Prototype has a tendency to make coders lazy, attaching everything to the this operating and using event and function binding ...

Probably the most commonly needed Function for a Web Application Developer (WAD), is document.getElementById. As you will most certainly need to retrieve HTMLElements from the DOM by the elements ID. Using getElementById is perfectly valid, but has potential drawbacks such as:

First, lets make sure we are all using the same Framework versions, because these teams have been cranking out frequent changes. This discussion will use the stable release of Prototype 1.5.1 and YUI 2.2.0. This article will analyze the speed of creating small dummy objects to get an idea of which approach is better. Before, starting, Id like to take a moment to thank the YUI guys for following rigorous coding standards and well documenting ...