Hacker News Reader

Comment by thurn | Hacker News Reader

Animation is usually the biggest pain point with frameworks like this -- and it usually feels like a complete afterthought for framework designers. Of course you always have the simple CSS-style stuff (here's a list of properties you can attach transitions to) but as soon as you get into anything more complicated it all falls apart.

View on HN

> Animation is usually the biggest pain point with frameworks like this -- and it usually feels like a complete afterthought for framework designers.

It tends to be. The only (popular) JS framework where it's a first class concept is with Svelte. There's a basic set of transitions and the framework handles the post-out-transition removal (which is annoying in a lot of frameworks) but there's also custom CSS animations where a JS-defined curve is rendered into CSS [1], semi-automated FLIP animations for non-transitioning nodes [2], and deferred transitions where the outro of one element is sync'd with the intro of another [3]. There's a few other things like springs and whatnot but I consider the package as a whole to be a significant advancement in the state of the art.

[1] https://svelte.dev/tutorial/custom-css-transitions [2] https://svelte.dev/tutorial/animate [3] https://svelte.dev/tutorial/deferred-transitions

The only other framework I know of that's tackled it in core is Inferno but I haven't read through their implementation in detail.

Flutter is also very good at animation. I suspect that a significant part of the motivation for Flutter was Android developers getting frustrated with the repeated unsatisfactory attempts at an animation API for Java Android. I think there are like 4 different animation APIs in Java Android now.

The compose APIs for animation are quite nice on Android now

CSS transitions are fairly restricted, but animation in CSS is substantially more capable than transitions if you’re using the animations API instead: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animati...

CSS is pretty flexible. What kind of animations would you expect to be difficult to express?

> CSS is pretty flexible. What kind of animations would you expect to be difficult to express?

Interpolations of anything beyond basic properties such as size, orientation, opacity, color, stroke, and fill; vector shapes, particle systems, and generative textures come to mind.

There are intermediate possibilities. In theory you could "compile" the animation of a skeletal system with inverse kinematics to CSS, but I'm not aware of anyone going to the trouble.

If you're going all the way to skeletons, kinematics, particle systems, etc maybe you just need a game renderer. Say, Bevy, if you want a rust flavor.

No need to go that far. If you're just looking for the edge of where the capabilities of CSS animation fails, consider the pseudo-physics of various direct manipulations in touch UIs: eg. the bounce when you swipe to scroll and reach the last item, or swipe down again to refresh, or swipe to fling cards aside left or right, or pinch to zoom past the last zoom level, etc.

In some cases you could get a good-enough result by animating from arbitrary (ie. user controlled) starting point to one or more fixed end-states (eg. Three "flick right" animations, one each for flick up and to the right, right, or down and to the right), but at that point you might as well just use an animation library.

To restate things from a bit more mathematical perspective, interpolating position (even with control over easing etc.) only gets you so far. Ideally you would be able to set and interpolate higher derivatives of position over time (speed, acceleration, etc.) as well, without resorting to JS.

How important are animations in a UI? I typically find them annoying (because you have to wait for them).

Poor animation design has exactly the problem you describe. Animation in general is a very useful affordance, though: it allows you to convey the relationships between the various nodes and modes in your UI. That ranges from being able to do more than hard toggles on colors of buttons for different modes to actually being able to do push/pop on “stacks” within the UI, which is a concept mobile UIs in particular make heavy use of. Overuse of animation can be an accessibility problem, but having no animations or transitions can actually also be an accessibility problem because it can make it hard for people to build a mental model of what happened when navigation occurred.

I'd go so far as to state that anyone who 'hates animations' uses them daily.

The ones you don't notice are most often good - yet they are there. You'll notice degrading UX when they aren't. The ones you notice are quite likely bad, but that doesn't make the majority of aniation bad.

Anything, from a blinking cursor, to the highlight effect on your smartphone keyboard to the check-uncheck of a checkbox is animated. Subtle, but crucial.

I don't think these are the kinds of animations being referred to. They're instantaneous state changes. E.g., for the highlight effect you can just change the key image on press. It doesn't need multiple frames of animation.

So while it is technically an animation, I don't think it really requires any special GUI toolkit support to implement.

Simple sliding animations for going back/forward in mobile screens add so much more confirmation to what exactly is happening when you click an element. Or when you tap a button. That feedback you get when you interact with an element is often some kind of animation.

In game development, extremely important. And to increase complexity, they can also “delay” state updates from the actual state to what is presented to the user. The player's gold purse might already have that 10gp, but the gold counter at the top should only be updated when the gold icon completes it flight from the center of the screen. Also, this icon? It was originally rendered in the game layer underneath the ui, and has to change layers (which usually have very different layout algorithms) and un-chain itself from the camera movement during this animation, completely unnoticed by the player.

In modern UIs, even screen transitions rely on animations.

Sure, but I guess my point was, do they really need to? How much does it add?

I'm not necessarily saying they don't matter, more that I'd like to find out how much they actually matter, vs how much people think they matter.

The basic stuff is incredibly important, but there's also lots of fluff in many applications which is why you find it annoying.

My two go-to examples:

- The shopping app I use has some kind of points system and some items give you "boost". I hate the concept and don't even care what it does because adding those items animates a bar filling up and take extra 4s while I'm trying to do this as quickly as possible. This is a terrible use of animations.

- Any app where you can rearrange a list needs an animation for when you hold an item and try to move it. Specifically, other entries shouldn't instantaneously jump around when you cross some threshold. There's lots of subtle ways to achieve this, but one of my favorites is greying out the old space and springing items up/down as you move the chosen one around. This animation is almost required, because the experience is jarring otherwise.

But this feels like something that can be handled with instantaneous state changes. I feel like pretty much any GUI implementation could handle it. I assumed the kind of animation support referred to was timed animations, which need multiple frames to complete.

Reply on news.ycombinator.com