The case for async/await-based JavaScript animations

async/await is one of my favorite features of modern JavaScript. While it's just syntactic sugar around Promises, I've found that it enables much more readable and declarative asynchronous code. Recently I've started to experiment with async/await-based animations, and I've found it to be an effective and standards-based pattern.

The problem

There is no shortage of great JavaScript animation libraries available. For most use cases, GreenSock is the gold standard and the library you should default to (and I am saying this as an author of a "competing" library). GreenSock, like most animation libraries such as Tween.js, anime.js, or mo.js, has a robust and comprehensive animation-oriented API. This API works well, but like any domain-specific solution, it's an additional layer of programming semantics on top of the language itself. It raises the barrier of entry for newer programmers, and you can't assume that one bespoke API will integrate gracefully with another. What if we could simplify our animation scripting to be more standards-based to avoid these issues?

The solution: Enter async/await

async/await enables us to write asynchronous code as though it was synchronous, thereby letting us avoid unnecessarily nested callbacks and letting code execute more linearly.

Bias warning: For the examples in this post I am going to use Shifty, an animation library I am the developer of. It is by no means the only library you could use to build Promise-based animations, but it does provide it as a first-class feature whereas it's a bit more of an opt-in feature for GreenSock and other animation libraries. Use the tool that's right for you!

Here's an animation that uses Promises directly:

import { tween } from 'shifty'const element = document.querySelector('#tweenable')tween({  render: ({ x }) => {    element.style.transform = `translateX(${x}px)`  },  easing: 'easeInOutQuad',  duration: 500,  from: { x: 0 },  to: { x: 200 },}).then(({ tweenable }) =>  tweenable.tween({    to: { x: 0 },  }))

This is straightforward enough, but it could be simpler. Here's the same animation, but with async/await:

import { tween } from 'shifty'const element = document.querySelector('#tweenable');(async () => {  const { tweenable } = await tween({    render: ({ x }) => {      element.style.transform = `translateX(${x}px)`    },    easing: 'easeInOutQuad',    duration: 500,    from: { x: 0 },    to: { x: 200 },  })  tweenable.tween({    to: { x: 0 },  })})()

For an example this basic, the difference isn't significant. However, we can see that the async/await version is free from the .then() chaining, which keeps things a bit terser but also allows for a flatter overall code structure (at least once it's inside the async IIFE wrapper).

Because the code is visually synchronous, it becomes easier to mix side effects into the "beats" of the animation:

It gets more interesting when we look at using standard JavaScript loops with our animations. It's still weird to me that you can use a for or a while loop with asynchronous code and not have it block the thread, but async/await allows us to do it! Here's a metronome that uses a standard while loop that repeats infinitely, but doesn't block the thread:

Did you notice the while (true) in there? In an a non-async function, this would result in an infinite loop and crash the page. But here, it does exactly what we want!

This pattern enables straightforward animation scripting with minimal semantic overhead from third-party library code. await is a fundamentally declarative programming construct, and it helps to wrangle the complexity of necessarily asynchronous and time-based animation programming. I hope that more animation libraries provide first-class Promise support to enable more developers to easily write async/await animations!