The Bricklayer's Missing Mallet: On the Disrupted Cadence of an Unfettered Animation
There is a piece of received wisdom in our craft, so often repeated it has taken on the weight of an axiom: animation, when used well, guides the user. It soothes the jarring jump from one state to another, it illustrates relationships, it provides a tangible sense of feedback. It is the polish that transforms a functional interface into an elegant one. We are taught to value this smoothness, to chase it, to measure our success by its presence. But in our pursuit of this smoothness, we have, I fear, cultivated a dangerous blind spot. We have mistaken the rhythm of the animation itself for the rhythm of the page as a whole.
It is the work of a bricklayer that comes to mind. A master bricklayer works with a steady, unbroken cadence—pick up a brick, butter it with mortar, tap it into place. The rhythm is the work. It is efficient, predictable, and produces a sturdy wall. Now, imagine if every time the bricklayer reached for a brick, a beautifully choreographed but utterly unpredictable dance began. A flourish of the trowel, a spin, a leap. The animation of the brick’s journey to the wall is flawless, but the bricklayer’s rhythm is shattered. The wall’s progress stalls. The dance, intended to enhance the work, has become its primary obstacle.
This is the subtle tyranny of the unfettered animation on our pages. A button may ripple with a gorgeous wave of color, a modal may slide in with a satisfying ease, but if these animations are not explicitly timed and contained—if they are not given a clear start and, more importantly, a solid, predictable end—they become black holes for interaction. They create a period of limbo where the user’s intent, their click or tap, is lost in a non-interruptible performance. The user is left waiting for the page to ‘catch up’ to their own expectation of immediacy. The smooth animation has created a profoundly jarring user experience.
The Illusion of Fluidity
We have become so focused on the native feel of a 60fps transition that we’ve ignored the fact that the most native feeling of all is responsiveness. A user taps a button; the button should respond. Immediately. The problem often lies not in the animation’s performance, but in its priority. An animation controlled by JavaScript, especially one that manipulates layout or paints extensively, can easily block the main thread. While the browser is busy calculating the beautiful transition, it cannot process the next user input. The page, for all its visual fluidity, is temporarily paralyzed.
The critique, then, is not of animation itself, but of the unexamined belief that any animation is better than none, that smoothness is an absolute good. The true craft lies in understanding the cost. It lies in knowing when to use a CSS transition that the browser can offload to the compositor, and when a JavaScript-powered spectacle will hold the main thread hostage. It lies in setting explicit `animation-fill-mode` and transitionend callbacks to ensure the state of the interface is predictable the moment the performance ends. It is the discipline of the bricklayer, ensuring that every tool, every movement, serves the larger rhythm of building the wall, rather than interrupting it for a solo.
The next time you add an animation, ask not just if it is smooth, but if it is respectful. Does it honor the user’s action by concluding with certainty, leaving the interface ready for the next command? Or does it demand that the user sit through its performance, breaking the rhythm of their intent? The best animation is not the one you notice for its beauty, but the one you don’t notice at all, because it integrated so seamlessly into the responsive cadence of the whole. That is the quiet, necessary weight of the bricklayer’s mallet, ensuring every element is truly, finally, set.
Notes & further reading
A few pages I came back to while writing this: