Let's Talk about the Web Animations API

Let’s talk about the Web Animations API

This is an introduction to a tutorial series on the Web Animations API coming to browsers. I've updated the series content in June 2016, as Chrome and Firefox have both rolled out major updates (and some small spec changes). If you have thoughts/questions or see that I’ve misinterpreted the spec, please reach out to me on Twitter, @dancwilson.

In Summer 2014, Google announced Material design with a representation in web through Polymer… using a polyfill for the upcoming standard Web Animations API.

I hadn’t heard of this API, but I was intrigued, especially since it talked about a MotionPath effect. That wasn’t implemented yet (you’ll find out what happened in Part 5), but its goal of providing a way to unite the CSS, JS, and SVG ways to animate kept me interested. A year later and Chrome and Firefox have started implementations, the polyfill’s progress is steady, and it’s time to take a look at it in earnest.

But so few people are talking about the WAAPI! My hope is to start a series of posts highlighting the features that are in browsers (and the polyfill) now, exploring why we want this API, and figuring out the nuances. Hopefully we will also get more people discussing, and working with, this API.

What is the Web Animations API?

We’ll start this exploration by figuring out what it is and what it is trying to accomplish.

Animation has progressed nicely in the last half decade, with great CSS support and new additions to improve JavaScript. But each approach to animation still has a slew of cons to all the pros they provide.

CSS has hardware acceleration for smooth transitions and support is built into the browser, but rules are declared in CSS and require jumping through JavaScript hoops to get values dynamically changed.

requestAnimationFrame has good support and lets the browser optimize when to animate, but it can still hang up if there is a lot of other JavaScript running. It also often requires more math to get timing down.

has good support and lets the browser optimize when to animate, but it can still hang up if there is a lot of other JavaScript running. It also often requires more math to get timing down. setInterval introduced many developers to animations, but it is imprecise and can lead to stuttering animations.

introduced many developers to animations, but it is imprecise and can lead to stuttering animations. jQuery.animate() introduced several other developers to animations, but often has performance issues.

introduced several other developers to animations, but often has performance issues. Libraries such as Velocity and GreenSock (GSAP) improve JavaScript performance and have been tested in many situations to be the best they can be. They still, however, require maintaining and loading external libraries.

In general, we like it when browsers support as much as they can, and they take over the optimizations. Browsers now have document.querySelector because we saw the value jQuery provided to select DOM elements. So utilities in libraries moved into the browser natively. Ideally, we could pack as much animation control at the browser level. These libraries can then focus on providing newer features, and the cycle can continue.

The Web Animations API tries to do this. It aims to bring the power of CSS performance, add the benefits and flexibility of JavaScript (and SVG animation, which we will talk about in a future post), and leave it to the browsers to make it work well.

Let’s solve this by adding something new!

At a former job, we received an email stating that they knew we had too many places to check for company announcements - email, monitors in the office, Yammer, Google Chat, and a intranet/wiki. So to solve the problem they announced… they were adding a blog.

My first thought hearing about the Web Animations API was the same thought I had hearing my company was adding a blog - this will only make things worse. Sure enough, the blog didn’t centralize anything, it just added one more place we had to check for news, and it died out.

This feels different, though. Reviewing a spec (first time I’ve really done it to this extent) shows the attention put into this. It’s not meant to replace existing behaviors (although some browsers are deprecating some it seems…), but instead unite the various ways and allow them even to interact. The syntax is similar to CSS but adds the options of variables, controls, and finish callbacks.

Next Time…

So the Web Animations API is new, and starting to be implemented (currently in Chrome and Firefox) in addition to having a polyfill. Next time we will actually start looking at what it provides developers… with examples!

Check out the rest of this series: