Easily Improving jQuery Animations
We’ve all used jQuery’s animate() to create nice effects on our web pages. Then, with the introduction and the rise of CSS3 they told us that our code was rubbish. They suggested that we dump all of our jQuery-based animations (and in general JavaScript-based animations) in favor of CSS-based ones.
This change forced us to deal with a lot of browser (in)compatibility issues and lack of features; not to mention the impossibility to run them on older versions of Internet Explorer. The pain was justified by the fact that CSS animations are faster than JavaScript ones. At least they told us so. It this true? Is jQuery’s animate() so slow? Is there a way to enhance it easily without changing our code? The answer is yes.
In this article we’ll see some of the limitations of both ways of creating animations and then how we can achieve better performance with our jQuery code.
What’s the Problem With jQuery?
We all know and love jQuery (actually some people don’t). This library, designed to simplify the client side scripting of HTML, has helped hundred of thousands (no real data intended) developers all over the world. It makes things like HTML document traversal and manipulation, event handling, Ajax, and much more a piece of cake, taking the burden to deal with all the browsers’ incompatibilities and bugs.
Among its features, jQuery also allows to create animations and effects. With it, we can animate CSS properties, hide elements, fade them, and other similar effects. However, jQuery’s design goal has never been to be a performant animation engine, and it was never meant to support really complex, cpu/gpu-consuming animations. As a confirmation of this fact, jQuery’s memory consumption often triggers garbage collections that cause issues while an animation is performed. In addition, behind the scene jQuery uses setInterval() instead of requestAnimationFrame() (read more about requestAnimationFrame()) to run animations, that doesn’t help in producing high frame rates.
Due to these factors, people “who know best” evangelized the use of CSS to create our animations and effects.
CSS Animations and Transitions
Let’s make it clear: CSS animations win over jQuery’s ones. jQuery can be several times slower than CSS when talking about animations. CSS animations and transitions have the advantage of being hardware accelerated by the GPU, which is really good in moving pixels. This factor seems a great improvement especially in those situations where performance is critical, like mobile devices. This is awesome, isn’t it? The truth is, all this thing has limitations and issues.
The first limitation is that not all CSS properties can be improved by the GPU. Therefore, the assumption that using CSS animations will always win is just false. Another problem is that CSS animations aren’t portable, at least not in all browsers you may be targeting. For example, transitions don’t work in versions of Internet Explorer 9 and below. As if it weren’t enough, animations in CSS are currently based on percentages rather than time (seconds or milliseconds). What this means is that unless you’re using a preprocessor like Sass or Less, it can be a real pain to change the duration of an animation after you’ve completed it. Finally, CSS animations require a lot of vendor prefixes to type. Yes, we can delegate a tool to deal with them, but that’s just another thing to worry about.
In addition to the previous considerations, there are other good reasons not to discount jQuery animations. They have more to do with the lack of skills than a weakness of the technology itself, but are still worth mentioning. If a developer used to create animations with jQuery, chances there are that the developer was unable to use CSS to perform the same task. Maybe it’d take the developer so long to create the same effect in CSS that the effort would not be worth the benefits. Or may the developer didn’t want to learn yet another technology to create highly customizable animations. This isn’t something to be ashamed of. Everyone has their limit in a given field.
The whole point here is that we want animations created using jQuery to have better performance, so that we don’t have to convert them into CSS animations. Fortunately for us, a solution does exist.
Improving jQuery’s animate()
The answer to the problem of jQuery’s animations is called Velocity.js. Velocity.js is a jQuery plugin that re-implements
Unlike jQuery 1.X that works with ancient versions of IE, Velocity works with IE8+. For most projects this should not be a major problem.$.animate() to produce significantly greater performance (making Velocity also faster than CSS animation libraries) while including new features to improve animation workflow.
At this point you’re wondering how the use of Velocity.js can impact a codebase. The answer is “in a ridiculously way.” All we have to do to integrate Velocity.js is to download it and include it in the web page we want to use. The last step needed is to replace every occurrence of $.animate() with $.velocity() without changing any parameters! This change is as easy as performing a search and replace in our text editor or IDE of choice.
Once done, our animations will have an immediate boost in performance. This is awesome as we can reuse our knowledge without impacting the codebase much. In addition, as it’s a jQuery plugin that maintains chainability, we can continue creating that “chain of method calls” typical of jQuery.
Conclusions
In this article I’ve described some of the issues that affect jQuery-based animations. We’ve discussed why CSS animations have been pushed so much over the last few years as a replacement for jQuery. Then, I highlighted some of the limitations of CSS and some of its drawbacks when it comes to performance. Finally, I’ve briefly introduced you to Velocity.js, a jQuery plugin that allows you to improve the performance of JavaScript animations and effects almost without changing the source code.
This article is only an introduction to the comparison between jQuery, CSS, and JavaScript animations. If you want to study in-depth this topic, I strongly suggest you to read the following articles written by the author of GSAP and the author of Velocity.js: