Simplified Animations on the Web

♪♪♪ I am getting old. Speaking of getting old, who remembers this? How's your knees and back feeling? Have you taken your Advil today? All seriousness, MacroMedia Flash, for those who did not know, was the best thing to ever happen to web development. I will die on that hill. I think it's great. Just like I will die on the hill of OneBase indexes.

MacroMedia Flash was great because not only could you bring in like your designer friends who knew how to make things look great, but they gave you this cool little thing up here at the top called a timeline. For those who didn't get a chance to experience Flash in all its glory, a timeline allowed you to take, say, a circle. Could just be an object, could be some text, could be anything. You could select the spot on the timeline where you want your object to like how long you want an animation to take. You would move your object to that timeline, move the object in space, select the timeline, and then say, create animation tween. And then when you hit play, it would just move. And you could do a lot of other things with this. Like you could warp it into a different shape completely. Flash was really cool in that case and we lost a lot of the good that Flash brought to the web. We're starting to get it back though. So we're going to talk about animations on the web, how you can make them simple, how you can make them better.

You can find me not on Twitter too much these days. I'm on the Cooler Blue Sky site. If you're not on Blue Sky, join. It's a lot more fun and nice over there. But let's dive into animations. Animations on the web have had a very, very fun history. Quick show of hands, or not show of hands, whoever's going to shout it out first, what browser had the first animation support? Anybody? You're all wrong. It was Internet Explorer. Internet Explorer. Internet Explorer. Internet Explorer. All the joys of Internet Explorer 5.5. Now you might be wondering, Mike, how did this happen? How did we get animations in Internet Explorer? Internet Explorer shipped with this really cool meta tag. Because this was around the time when we were still shipping separate HTML files for all of our different routes.

It was a simpler time. It was a better time. But they gave you this meta tag where you could define an Enter animation and an Exit animation. You'd give it the HTTP equiv. Then you would set the content to be a reveal transition, whether that was three seconds, 500 milliseconds. And then for the transition, you would actually have all of these built-in transitions provided by the browser for animating things from left to right, right to left, doing that nice little circle grow in the middle. Really, really top-notch stuff that existed in 1999, 2000. Really cool stuff.

And then Internet Explorer 5.5 died. And we lost this animation. We wouldn't see animations again until we got keyframe animations on the web, roughly around 2007. And this was something that Safari had first. We don't hear that often, but Safari had something first, folks. With keyframe animations, you would define a start and end point. And then using CSS, you'd be able to define that animation inside of your code. Now, this was great, because you could just code it and then have the animation play and take off. But the animation kind of lacked a lot of fine-grained control. You couldn't really catch it mid-animation. You were kind of off on your own.

JavaScript animations came along after that, where they basically re-implemented a JavaScript animation engine. And probably the one that people are most familiar with is GreenSock. There's nearly a dozen animation libraries out there. jQueryAnimate, anybody? The fun thing with these is that the animation would just work, but you'd have so much JavaScript to do simple things like this. If anyone's ever took a look at jQueryAnimate for fun Friday night reading, their animation timeline is a set timeout. You didn't shit. No one gasped at that. Yeah, thank you. Set timeout for an animation timeline is terrible, especially because this was before we had requestAnimationFrame. So code was very slow. It was great for the time.

But trying to run it on modern day stuff, you're going to see the performance impact for it. Then we got Web Animations, which came out a few years later. Web Animation took all the ideas of GreenSock, all these JavaScript animation libraries, and built it right into the browser. So all of this is just very simple animation code.

We have a collection of spheres. We want to animate them. We're going to give them some key frames. We're going to set some timing. We're going to use this fancy cubic bezier curve. And then we're just going to animate everything and offset it so that by the time they play, we have this nice little animation stagger effect.

But what's cool is that we can pause this. We can hit play. We can catch things just as you see the squash and squish effect, or the stretch and squish effect of this animation cycle. So this is all part of the platform. It's all great.

What's the pain point with this is that as you try to coordinate all these animations, you're going to be writing far more JavaScript to get interactions happen. You want to have an animation play. And then once that's finished, you want to trigger another animation. There's no great way to do that other than just waiting for that transition.

So there is a better way for doing this these days, and that is view transitions. View transitions, if you have not heard of them, they are probably the coolest thing to come to the web. Now a very, very technical definition of what view transitions are. The view transitions API provides a mechanism for easily creating animated transitions between different DOM states while also updating the DOM contents in a single step. You update the DOM, and it'll transition between the different states. Pretty easy.

We can actually think of it as just getting the DOM changes and then the snapshot between the two. But for people who like to see visuals, let's say we have a list of items. We want to remove a list, one list item. We remove it from the DOM. The browser will detect that that has changed and actually transition between all of the different states.

Pretty cool. Pretty cool. But what does that actually mean? So it all starts off with this document.startViewTransition. Now the start view transition is just a function. It accepts a callback. It could be a promise. But all it really does is say, hey, something's going to happen in here. Let's go ahead and track it. So we just have a simple layout over here. It's just a circle. And we're just going to randomly change the alignment property on this grid.

So we do have startViewTransition. And now we have a transition. It's not a great transition because it's just a fade. But it's better than doing nothing. So we're tracking this. We're getting a little snapshot of that. What if we want to go and do something more? Well, we could actually use this viewTransitionName property in CSS to actually tell the browser, hey, this thing is going to change its position. We should track it. So same exact demo. Only thing that's been added, viewTransitionName. The problem with random is that sometimes it'll give you the same exact values so you can't tell. But by just clicking it, we're not coding any of the animation that is happening here. It is simply the browser knowing I was here, I'm here, figure it out, which is great.

We can even go a step further by doing something that was a pain to do in web animations. And that is animateDisplayNone. This is a demo that's so good. It was from a buddy of mine, Adam Argyle, who works on the Chrome team. I didn't even want to rewrite it. It is literally a periodic table.

So let's go ahead and zoom out real quick. Let's just filter out any element in here that is not a metal. Transitions. Let's get all the ones with the EM suffix. Now let's change their order. Nothing in this code actually controls the animation steps. It is just changing some order properties on the grid itself.

We can even remove this super fancy Adam showing off kind of animation timing. And we can see it a little bit more clear. We don't get any of the jumping. All of that is incredible because now I can just change the layout. And I don't care about how that is going to affect or what the browser should do. Don't quit.

Now I said how this is working, is that it's using snapshots. Basically, startViewTransitions look at the DOM, and it will actually take a flattened DOM structure and create this pseudo tree called ViewTransitions. Each element in here is an example of that box, so all the elements that were listed in there. Now inside each of these groups, we get a pair. We get an old and a new. So now if we want to animate something that was leaving, well, we assume there's only going to be an old. And there's not going to be a new thing that's in there. So we can code that CSS specifically using only child. We can also do that for new if the opposite is true, if we only want to animate things that are entering the DOM.

Now as cool as that periodic table example is, it's not really practical unless you are in the scientific and chemistry fields. You're a bunch of web developers. That's not practical to you. Here is something that is practical. I'm one of the few people that uses Apple Music, but there's a dozen other people that also use Spotify. This is a layout that people see pretty often. It's a slide-out menu with a queue of songs, and it just moves the main content over to the side. It doesn't even need to be music related.

You could have a slide-out menu. You could have a whole bunch of UI where this is how you reveal more information. How do you do that in web animations? So here it is. Our web animations approach is actually going through and using the flip animation approach where you have bounding client rec, where you get the X, Y, width, and height. We're going to go through it. We're going to grab our layout change, apply a new layout here, grab that again. Now this is just going to be all the animation needed to animate the display none property. We basically have to take that element, put it in the DOM structure, and then move everything back to as if it wasn't there, setting the opacity of that element to zero. And we're doing a lot of position absolute. We're doing some cleanup. We're animating it, and then we have to clean up afterwards. And that's just for one element. Now we get to do the whole thing again for the other element. You can kind of see how if you have more involved layout and UI, you're coding all this together. So we are at 118 lines of code for a demo. No thank you. Let's get rid of this. Let's just do the view transitions. And instead of having all of that hard-coded animation logic in here, let's move it to these two keyframes. We have a from and a to to scale an element up and then fade in. We want something to show. We play it as normal. We want something to hide. We just play it in reverse. Browser's animation support in here for CSS is actually quite good. So when we go back to our demo, we can use a view transition and know that all of this is maintained by the browser. I don't really care where this element's going. I have nothing in my CSS for that blue element other than give it a name. This is only getting, hey, play this animation if I'm leaving. Play this animation if I'm not leaving.

It's great. It's so much better than what it used to be. Now, other than just showing pure vanilla examples, what about working with frameworks? Because most people are working with frameworks. I think it's a safe assumption. Who uses Astro? Everyone, go check out Astro. It's pretty awesome. Astro is a really great example of a project that saw view transitions and were like, yes, please, we needed this yesterday. So much so that they have a built-in support for view transitions as part of their core offering. So all you have to do is actually give your main document this view transition element, and you get view transitions for free.

So there's this really cool example that was shown a while ago where someone made this little playlist where you could click on all the elements. And using Astro's API, he built out all the different animations and has everything up here running. And this is great. Go to this person's GitHub URL if you want to mess around and just see how this works because it is fascinating. I'm not in the Astro ecosystem. I'm in the Angular ecosystem. I know, I know. Keep your comments to yourself. But Angular also has a great story in here as well. So I built this demo basically recreating that other one. And you can see the code for all this up on GitHub. But here is that same exact demo, and we have view transitions happening. It works. What's even great is if we go up here and we just click that, when we go back, the scroll position gets maintained, which is super important because otherwise you're going to have this jarring user experience and the whole animation was for nothing. Using Peaceful Guitar, that works out.

Now how this is working is behind the scenes, we're actually hooking into the view transitions API. I said that that callback just accepts any DOM changes. It also has a couple of parameters in there that you can get access to. So we can get the current state of the animation, figure out where we are coming from and where we're going to. So that way, if for whatever reason in this case, I want to dynamically assign a view transition name to an element, I can do that by just saying, get me the current transition. Am I going to this element or not? And in my component, I can dynamically assign this view transition name.

So this is great, pretty simple. I took it a step further. Whoa. I took it a step further and made another one because I have nothing else to do. I made another Spotify example. I really love building music player apps for some reason. What's great about this one is that there is dynamically generated view transition names for everything on here. And took a little page out of Astro in the sense that all of this is actually computing a new transition name and inserting the styles for this in the DOM at runtime. So we're using computed style sheets. We're updating them every time a new element gets entered into the DOM. So that way, when we go to, say, this example, and in fact, if we go and open up the animation inspector and slow it down a little bit, you can see what is actually happening. And we can transition it. And what's even better is, let's just pause the animation. We can just pause this, inspect it. You can see over here, we get the view transition tree. Here's everything that we could possibly animate. Total overkill.

Probably don't do this, but you could. So let's wrap up real quick. View transitions are awesome. This is literally the thing that has made me the most excited about the web. I could care less about JavaScript and signals. View transitions are the thing that everyone should be paying attention to. But it's not the only thing in the animation world.

There's scroll-driven animations without having to reach for JavaScript. There's animation compositions. That way, you can change how an animation or how multiple animations interact with one another. And there's transition behavior, which allow you to go from indeterminate states between display none or display block.

So a lot of animations out there. And it's never been easier to get started with it. So you can check out the slides up online. But thank you so much.

Now that you're done with your talk, how does that make you feel? Like I could do a cartwheel. Love that. There is a lot of space right here. And I have full faith in you to do that. I'm displaced. All right, onto some questions that we have. Again, everyone, please submit your questions on Slido.

Let's do this one. The first question, people are wondering, does view transition run on a separate thread like keyframes rather than the main thread? So it is hardware accelerated. What's interesting about it, if you imagine trying to animate width and height, that's all run on the main thread. If you do transforms, that's off thread. View transitions actually are not animating actual elements, just essentially images. So all the transformation work that's being done under the hood, it's all using hardware accelerated approaches, using transforms, opacities. You're just not computing it. It's the browser doing it for you. So it's all efficient. Nice. I love the sound of the browser doing everything. I'm lazy. The browser can do it for me, the better. Oh, we all. Awesome.

The next question has many votes. Does React have support for view transition? Yes, it does. React does have support for it. There is a use view transition hook that I saw. It basically gives you the same capabilities that my Angular directive did. You are essentially just assigning a view transition name to whatever element that you're applying it. I haven't tried it, but I've seen it on NPM.

Nice. Do you feel like all the different ones support a similar capability? Or does one view transition better than the others? They all support them pretty well. I think React and View are the only ones I haven't messed with personally. But what's great about it is that you don't necessarily need too much work to just integrate it yourself. Because it is just part of the browser feature, and it just works.

Nice. Yeah. OK. What about performance? That's all the questions. Yeah, performance is really great. Obviously, just go try it out and inspect. In fact, if you open it up, ran it on simulated slowdown CPU, you brought in paint flashings to see if you're doing any excessive repaints, the performance itself is incredibly smooth. A lot better than probably your own custom bespoke web animation library. At least from my measurements, there's no major impact on it. And again, if you're animating 300 things, expect bad things, because the browser should not be animating 300 things. I can't think of any use case for that.

Exactly. Yet you would see the things I've seen. Well, that's why you're in the therapy chair, to talk about all the things that you see. Amazing. OK. Next question. Which browser support view transitions? That is a great question.

So currently, it is supported in Chrome or Chromium browser, so Edge, Arc, Chrome itself, and Safari. They added that recently. There's a different level of it where you could do view transitions with multi-page apps, so your old school HTML pages. That is currently only in Chrome, with some work being done in Safari. Firefox is kind of lagging behind, but they have expressed interest in adding it.

All right. Sounds like Firefox has a little bit of catch up to do. OK. Next question. How would you keep image persistent across two different views? And this is referring to the Spotify demo. So keeping images persistent across the different views, as long as it is part of that snapshot tree. So if I have image one and image two, as long as those view transition names match, the browser will treat it essentially as if it's one image, where you can have the animation just work. It's technically going to fade at some point to the new image. But as long as the names are the same across the transitions, it'll match up and make sure that, OK, here is where this image comes from. Here's where it's going. Make it just look like it's a seamless transition.

The tricky one is video. Because video, if you go to a new page, it's going to play, and it's going to cause all sorts of chaos. And what do you do about that? Hope the user don't notice. Ha ha ha. Distract them. Yeah. OK. Is it a pain to rely on this method across different screen sizes? Which method? Assuming they mean view transitions, yes and no. Because it is all mostly CSS-driven, you can integrate with media queries pretty easily. So if you want an animation to run on one form factor, you just set those transition names in a media query. If you wanted to run a different animation in a larger screen, you do that as well.

Because it is all mostly CSS-driven, you can integrate with media queries pretty easily. So if you want an animation to run on one form factor, you just set those transition names in a media query. If you wanted to run a different animation in a larger screen, you do that as well. You can even hook into media queries that are like, I don't want any animations, or I want reduced animations. There's preferred reduced motions. You can have it just be a natural fade, or you could be pretty strict and just remove any animations on it.

OK. It works really well. Wow, we are flying through these questions. I'm just firing them at you. The next one is, how can you animate the shape of elements, like in the Circle to Box demo? So in the Circle to Box demo, you are essentially just, in one part, it had a border radius of 0. In the other part, it had a border radius of 50%. And the browser just figured it out. It's a little bit misleading in the sense that there is not a direct morph. You don't see it up in there. I see it on the projector. But there's a little fade animation, or kind of amoeba animation, I call it, where it's just animating the border radius. You don't necessarily get that natural morph. But if it happens fast enough, it doesn't need to be that detailed. Your users won't really pay attention too much. So this slide was a little bit of a lie. Sorry. No worries.

Thank you for answering all the questions. That's all the time we have. Make sure to practice mindfulness and draw on your boundaries and all that stuff. Thanks. Same time next week. Thank you so much. And this is our last stop before lunch.