Okay…it's time to make that change to PostCSS!

Before we get stuck into exploring what is available, there is a key question that I am sure you will be asking—how come we've been exploring animation using JavaScript, when this book is clearly about PostCSS?

There is a very good answer for this—not only are we exploring the different routes we might take to transition to PostCSS, but at a more basic level, whether we can make the change. This might sound contradictory, so let me explain all:

A key limitation of animation is the FPS count, or Frames Per Second—jQuery's standard .animate() method is notoriously slow, and has not been optimized for speed. The FPS count on our animation at the start of this chapter was significantly lower than that of Velocity. The same applies for the alternative Transit library that we also covered earlier in this chapter.

Making the switch to using CSS will improve the frame rate, but CSS-based animation is not yet sufficiently powerful to manage complex animations. It means that we as developers have to assess any requirements for a project, and weigh up whether CSS-based animation will work, or if we have to fall back to using JavaScript-based libraries.

This translates through to using PostCSS—it may be tempting to use CSS-based animation for a project, but this will only work if our animation requirements are such that it is not going to result in an overly complex, difficult to manage, solution.