Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

The State Of Animation 2014

The post-Flash era is hardly free of animation. CSS animation is quickly becoming a cornerstone of user-friendly interfaces on mobile and desktop, and JavaScript libraries already exist to handle complex interactive animations. In the wake of so much “CSS versus JavaScript animation” infighting, a new API specifically for web animation is coming out that might just unite both camps.

Further reading on Smashing: Link

It’s an exciting time for web animation, and also a time of grave miscommunication and misinformation. In 2014, I had the chance to travel the world to talk about using animation in user interfaces and design8. I met and interviewed dozens of people who use and champion both CSS and JavaScript. After interviewing so many developers, designers and browser representatives, I discovered a technical and human story to be told.

What you’re about to read is purely observational and as unbiased an account as you will be able to find on the subject of web animation.

Flash May Be Gone, But The Era Of Web Animation Has Just Begun Link

Since the era of Flash, it’s become fashionable to think of animation as little more than decoration, a “flashy” afterthought, often in poor taste, like an unwelcome blink tag. But unless we want to display nothing other than copy on a screen, animation is still very much our friend.

For user interface designers, animation reinforces hierarchy, relationships, structure, and cause and effect. Research going back to the early ’90s9 demonstrates that animation helps humans understand what’s happening on screen. Animation stitches together app states and offloads that work to the brain’s GPU — the visual cortex.

For interaction developers, complex visuals — from infographics on dashboards to video games on tablets — are impossible to create without animation to glue all the pieces together. If we want those things on the Internet, we still need animation.

Sadly, we have fallen behind in the motion design race. Products that use animation to benefit their users will succeed where their static or animation-abusing competitors will fail. As it stands, native apps are beating the pants off the web. App developers have been incorporating animation into their designs and fleshing out workflow and prototyping tools like Flinto10 and Mitya11 from day one.

But things might be turning around. iOS’ Safari team pushed out the CSS animation and transition specifications so that websites can look and feel as good as iOS apps do. Even Google has picked up on this, putting animation front and center12 in its Material Design recommendations, with careful do’s and don’ts to apply animations and transitions meaningfully, with purpose.

Animation is the natural next step in the evolution of our application and device ecosystem. It makes the digital world more intuitive and interesting for users of all ages. And so long as our devices sport GPUs, it’s not going away.

Animating All The Things Link

At its core, animation is just a visual representation of a rate of change over time and space. All animation can be distilled into three types:

Static animation runs from a start point to an end point, with no branching or logic. This can be accomplished with CSS alone13, as the abundance of CSS loading animations14 testifies.

Static animation

Stateful animation in its simplest form takes boolean input — a click to open a menu and a click to close it15, for instance — and animates between the two states. This is currently achieved in JavaScript frameworks by applying and removing classes with scoped CSS animation.

Stateful animation

Dynamic animation can have many outcomes depending on user input and other variables. It uses its own logic to determine how things should animate and what their endpoints are. It could entail “dragging” a page along behind your finger according to the speed of your swipe, or dynamically changing a graph as new data comes in. This is the trickiest kind of animation to accomplish with the tools at our disposal today. CSS alone cannot be used for this kind of animation.

Dynamic animation

More States != Dynamic Animation Link

The astute CSS developer might point out that, with enough states, CSS animation could closely resemble dynamic animation. This is true to a point. But truly dynamic animation has more end states than you can possibly anticipate.

More States != Dynamic Animation

Just imagine the humble loading bar. Having a different class for every percentage point of “fullness” would easily run to a hundred lines of CSS, not to mention the number of times your JavaScript would have to touch the DOM to update the classes and the browser repaints. We definitely could write a more performant dynamic loader with JavaScript alone.

CSS animation is declarative: Aside from a handful of pseudo-classes, such as :hover and :target, it accepts context from neither the user nor the user’s surroundings. It does only what its author tells it to do and cannot respond to new inputs or a changing environment. There’s no way to create a CSS animation that says “If you’re in the middle of the page, do this; otherwise, do that.” CSS doesn’t contain that sort of logic.

When CSS-first developers need logic, they often start by scoping CSS to state classes, with JavaScript handling the logic of when to apply which class. Frameworks such as AngularJS16 support states, and many UI interactions adapt easily to a handful of states like “loading,” “open” and “selected.” These animations also degrade gracefully in old browsers, providing a much needed UX boost where CSS animation and transitions are supported.


Interaction developers have had a different time of it. CSS animation is often too declarative to handle the things these developers want to build. Paying clients demand reliable animation across a wide spread of browsers; so, many interaction developers and their studios have done what all clever developers do: make labor-saving libraries customized to their own processes. Some of these libraries, like GSAP17 and Velocity4118, are available to and developed for the public. But many others will never be released in the wild, because the people and agencies who created them don’t have the time or money (or will) to support an open-source project.


This is a deeply worrying story that I’ve heard over and over again, and it suggests that many developers are reinventing the wheel without moving the web forward. There isn’t enough demand for something considered “nice to have” to support many competitors. It’s easy to see how libraries like GSAP must be commercial in order to survive, or how sponsorships buoy libraries like Velocity.

And Flash was a benevolent dictator, for its people did have a visual timeline UI.

Flash did a great thing by giving interaction developers and UI designers a universal workflow that accommodates all kinds of animations and a platform on which to edit them. But since Steve Jobs announced back in 2010 that the iPhone would never support Flash19, many former Flash developers have quietly gone into exile, taking their niche knowledge with them. Now, an entire generation of web designers has come online with relatively no knowledge of the possibilities and challenges we face when ramping up animation complexity.

But things are about to get quite… animated.

The Web Animation API: The Greatest An API You’ve Never Heard Of Link

The Web Animation API is a W3C specification that provides a unified language for CSS and SVG animations and that opens up the browser’s animation engine for developer manipulation. It does the following:

  • provide an API for the animation engine, enabling us to develop more in-browser animation tools and letting animation libraries tap into performance boosts;
  • give (qualifying) animation their own thread, getting rid of jank;
  • support motion paths20;
  • provide post-animation callbacks;
  • reintroduce nested and sequenced animations21 that we haven’t seen since Flash;
  • enable us to pause, play, seek, reverse, slow down or speed up playback with timing dictionaries22 and animation player objects23.

Here’s just one example of what the Web Animation API can do that CSS alone cannot24.

See the Pen Running on Web Animations API25 by Rachel Nabors (@rachelnabors26) on CodePen27.

Support Link

The Web Animation API has been over two years in the making, and its features have been rolling out in Chrome and Firefox nightlies for the past six months. Mozilla is the major force behind the specification. Meanwhile, the Chrome team has been prioritizing the shipment of features.

Microsoft has the API “under consideration”28 for Internet Explorer. Apple, surprisingly, has also adopted a wait-and-see approach for Safari. And we can only fantasize about when the API will hit those web app engines powered by ancient forks of open-source browsers29.

Early adopters who want to explore the API can try out a polyfill for the Web Animations API30, which is being replaced by Web Animations Next31 literally any day now (more about the polyfill and the API can be found on the website for the Polymer project32). However, for browsers that don’t support the API, the polyfill is still less performant than GSAP, the reigning champion of JavaScript-based animation libraries. Thus, the polyfill isn’t something interactive that developers will want to put into production for high-performance projects.

It will be some time before this API is supported across the board. With half of browser makers waiting to see how developers will use it and most developers refusing to use a tool that isn’t widely supported, the API faces a chicken-and-egg scenario. However, in an on-stage conversation with Google’s Paul Kinlan at Fronteers, I suggested that, were the API to be fully supported in a closed and monetizable system for web apps, such as Google Play, developers would be able to safely use it in a walled garden until it reaches maturity and fuller support.

Performance Link

The API’s authors and implementers hope that animation library developers will start feature-sniffing for the API’s support to tap into its performance benefits. Because the Web Animation API uses the CSS rendering engine, we can expect CSS levels of performance. Animations will run on their own thread as long as they don’t depend on anything happening in the main thread, such as JavaScript or layout.

Speaking of layout, reflowing remains one of the biggest processing hurdles for browsers. No CSS or JavaScript animation can get around it unless you’re pumping everything through WebGL straight to the GPU (which some clever in-house library developers have been doing). Aside from opacity and transform, animating the bulk of CSS properties will cause a reflow, a change in layout and/or a repaint of the pixels on the screen. The will-change CSS property helps some33 by enabling us to point at something and tell the browser, “That, that thing is going to change. You do what you have to do change it efficiently.” The hope is that as browsers get smarter about graphics, they’ll move those elements into their own layer or otherwise optimize the way they handle those graphics. It’s the first step in eliminating hacks like translateZ(0).

Such “performance hacks” often get slapped on as a magic fix whenever an animation is janking, but they often cause performance issues when used unwittingly. Performance decisions are truly best left to the browser in the long run. Fortunately, browser makers are scrambling to get fewer properties to trigger reflows, thus keeping them off the main thread. For animation library developers, this means that the Web Animation API could be a winning partner for performance in the near future.

Tools Link

Anyone working with web animation yearns for proper animation development tools: a timeline, property inspection, better editors, and the ability to pause, rewind and otherwise inspect an animation while debugging. The Web Animation API will open the guts of the CSS rendering engine to developers and the browser vendors themselves to create these tools. Both Chrome34 and Firefox are preparing animation features for their development tools. This API opens up those possibilities.

The Web Animation Community Today Link

Not many people other than those working on it are aware of the Web Animation API. The standards community is eager for real-world feedback from interaction and animation library developers. However, many developers feel that the standardistas live in an ivory tower, far removed from the rigors of the trenches, the demands of clients and the lessons learned from Flash.

The old king’s champion sent into exile by the very people he once served.

To be fair, the standardistas haven’t exactly come out to meet their audience in the field. To join the “official” Web Animation API conversation, you must jump through some hoops, and getting on the email chain threatens to overflow the inbox of any busy developer. Alternatively, you could get on IRC and join the conversation there — if only designers used IRC. The conversation that needs to happen is unlikely to happen if the people who have the most to say simply aren’t there. Vendors and specification authors will need to find more ways to reach out to their key audience or else risk building an API without an audience.

But the standardistas aren’t the only ones with communication problems here. As a community, we are very judgmental and quick to deride things that we deem unworthy, be it Flash or an API we don’t like the look of. Many of us invest our egos in our tools and processes. But those things don’t define us. What we create together defines us.

  • Animation library developers, read the specification35. It is long, but if GreenSock’s Jack Doyle can do it, so can you.
  • Interaction developers who don’t have all day to read a huge specification, just read the readme on the polyfill’s page36. It’s a perfect TLDR. Now that you know what’s coming, you will know when it might be useful to you, whether for optimizing your library’s performance or building an in-browser timeline UI.
  • Designers, prioritize JavaScript at work. Play with the polyfill, and play with GSAP and Velocity. Find out what these things can do for your work that CSS alone cannot accomplish.

With web animation, we have a rare chance to put our egos aside and come together as a community to build a tool with which future generations of designers and developers can build great things. For their sake, I hope we can.

“The art challenges the technology, and the technology inspires the art.”

– John Lasseter, CCO Pixar

Resources Link

Rachel Nabors has an updated list of resources on the Web Animation API. To join the unofficial conversation, look for the #waapi hash tag wherever you prefer to communicate.

Join the Conversation Link

Make a Difference Link

People who have some familiarity with C++ coding can help implement the API in Firefox44. Brian Birtles45 might even mentor you! And Mozilla is always looking for people to help write documentation on MDN46.

Minor corrections to the specification (grammar, spelling, inconsistencies, etc.) can be submitted as pull requests on GitHub47.

People to Follow on Twitter Link

(al, ml)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25 ''
  26. 26 ''
  27. 27 ''
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Rachel Nabors is an interaction developer and award-winning cartoonist. She travels the world, speaking about and training teams in the art of web animation. When not biking around her home city of Portland, she makes interactive comics at her company Tin Magpie. You can catch her as @rachelnabors on Twitter and at

  1. 1

    Nice article!

  2. 2

    You do not even realize how much i like your blog. I found it “by accident” today, but I think that I will stay here for longer ;)

    Once in the history (maaaaany years away) I was giving animation a shot. But I have quickly realized that I am more a drawer – making moving objects (especially using PC software) is not for me.

  3. 3

    Patrick Brosset

    November 18, 2014 9:59 pm

    Great article Rachel. I really enjoyed reading it.
    If anyone is interested the work for better web animations tooling in Firefox is starting to happen here:

  4. 5

    Your polyfill doesn’t seem to work on the latest Chrome. (38.0.2125.122) The cat animations continue to run out of sync.

  5. 6

    Just wanted to say this post helped validate the past 5 (almost 6) years of my life.
    After numerous discussions with people (confused clients, supervisors, etc.) regarding phasing Flash out, and accomplishing similar animated displays using Jquery, sprites, and CSS3, it’s great to see that “the industry standard” is no longer the bane of my existence.

    I was stubborn enough to start abandoning Flash in 2010 (started dabbling with Adobe Edge beta releases), and the day has come when others can comfortably do the same, and not fear being left behind.

    I mean seriously, why wouldn’t you want to use the languages you’re already coding with on your site(s) to add a little animation? It always made more sense to me than forcing people to download (and update) plugins, while always having to code for a fallback.

    I’ll definitely be taking a deeper look into the API!

  6. 7

    Fellow Flasher in exile/denial.

  7. 8

    Super članek Rachel . Res sem užival v branju .

  8. 9

    Great article, Rachel.

    Might check out the Web Animations API, although I’m one of those developers that needs proper support first to accept it into my daily coding..

    Also, thanks for clearly explaining all the different types of animation as I previously had no way to refer to them properly.

  9. 11

    Nice write up Rachael. I have a good resource to add to the list — Particularly from a comparative research point of view, it has a large collection of live working animation examples found around the web.

  10. 13

    Nice article and glad to see GSAP held so highly. I’ve implemented GSAP in our HTML5 banner work at our agency, having built a non-intrusive timeline-control (and other additional tools) that wrap the banner via PHP for development and review (using TImeline Max). Can’t say enough good things about GSAP and how it’s made creating some very complex banners our clients want, plus the community over there is astounding.

  11. 14

    Awesome article!

    Why don’t you mention though? :)

    • 15

      Very good question.

    • 16

      I interviewed many, many people while researching this article. Non of them used Polymer nor could definitively tell me what it is. Maybe if it gains more traction it will get mentioned in State of the Animation 2015 :)

  12. 17

    Nice article! The article is missing mentions of Famous and Famous-Angular next to GSAP and Velocity.

    Famous-Angular, as you can imagine, gives you a declarative, data-bound animation framework by combining Famous with Angular.

    There’s also Famous-Views for Meteor, a Famous-Meteor integration.

    These three libraries are game changers. Famous alone has twice the stars that Velocity has on GitHub, and 5 times the stars that GSAP has on GitHub, and growing at a much faster rate.

    Check out this nice demo, made with belongs in this article.

    • 18

      Why was this and so many other helpful comments marked down? This post’s comments are a gold mine. A grumpy former flash dev? (Spoken as a Flash refugee myself)

    • 19

      I stumbled on the “ University” tutorial section; it looks very thorough and accessible:

      Given two libraries that are close in performance and capability, documentation and learnability wins when it comes to actually getting used.

  13. 20

    Does css3 keyframe step animation support multiple row animation without JS?

  14. 21

    Thomas Williams

    November 20, 2014 1:26 am

    I see we are still burying Flash. Perhaps Rick Grimes and crew could make sure it stays dead this time. ;>


  15. 22

    In the example (, how does this line work?

    var catRunning = withWAAPI.animate(keyframes, timing);

    In particular, what is ‘withWAAPI’? I realized that’s the cat div id, but how does this work?
    I’d expect something more along the lines of:

    var cat = document.getElementById(‘withWAAPI’);
    var catRunning = cat.animate(keframes, timing);

  16. 24

    One of the best articles I have read on Web Animation…thanks for sharing your knowledge…

    One of the things I truly miss from the Flash days was a nice GUI developing Animations…you could really have fun creating and experimenting with animation in a visual way…Coding animations can be difficult for many designers…

    I Dream for a visual tool that outputs Web Standards CSS animation and / or JavaScript animation code…If not for production then at least for prototyping…

    Anyways great article…

    • 25

      I share your dream, Michael, as do many others. Hopefully, the Web Animation API will let us build those tools… in the browser… I can’t wait!!

  17. 26

    Nice article rachel, I am not aware of the web animation API until I read this. Thank you. Yeah its nice to have something to do the animation things.

  18. 27

    Pedro Ivo Hudson

    November 23, 2014 2:03 pm

    I did this a while back:
    I intend to update it with the current animation state.

    Great article! Thanks for sharing!

  19. 30

    I can’t wait for something to happen so that every site made in the last 6 months and beyond don’t send the fan on my brand spanking new macbook pro go into hyperdrive and try taking off from the desk.

  20. 31

    I for one am truly happy that Flash has been banished from this earth. Sure, it was a fun time working with the program but in retrospect a lot of plain awful abolishments of websites were made with it. Custom cursors, automatic audio, loading screens, complete movies before the ability to start, no context menu’s, memory slurpers etc.

    But unfortunately, you see it coming back again. Video backgrounds, parallax festivals, page loaders (!@#!) and full page backgrounds that aren’t compressed are already a sign things are getting worse again.

    With great power comes great responsibility, and most of us or our clients can’t handle it. Websites should inform in the first place, entertain as a second. This simple notion often seems too much to ask for.


↑ Back to top