Choosing Your Animation Adventure
(bright electronic music) (applause) - It depends, it's like, those two words are so painfully accurate, yet like, also, just not enough, and you get them as the answer to like every question you have about technology.
And you think, you're like, should I use this or that? And everyone's like, mmm, it depends.
And you're like, depends on what? I get angry very quickly. (laughter) I mean, it's definitely an answer you're gonna get if you ask anyone like, so, what should I use to animate this thing? And they'll be like, oh, it depends. (sighs) So today I wanted to dig into exactly what it depends on, and how we can navigate this space of web animation. Because we have so many options when it comes to web animation, like so, so many.
Which is wonderful and great, but also, makes this answer come up a whole lot.
So today, I'm hoping we can get you to a point where the next time you face a question like this, you'll know exactly what to do.
Ooh, the suspense, right? So we're gonna dive into the words of web animation, which totally looks like this.
(chuckles) It does.
I love the, oh, this, yeah, every time I see this, I'm like, yeah! So, we're gonna dig into the world of web animation to figure out, like, what do we use? What should we use to do the things that we wanna do? Especially when you have things like teams, or budgets, or timelines, or clients, you can't, I mean, with our tools on the web, we can make just about anything, do just about anything, if we really want to. And if you're not really sure about that, check out Codeban, people do crazy, wonderful things on there.
But, you know, let's talk about it a little bit more, perhaps, I mean, more practical, or at least like, day job kind of way.
So I'm gonna start with CSS, because that one is still my favourite.
I mean, I know, we're talking a lot about the CSS versus Javascript, CSS and Javascript stuff. But CSS is still my favourite, even after the last two days. It will always be. (chuckles) And part of the reason it is my favourite is, I'm kind of lazy, and if there's like a simple, easy answer, or a simple answer that will get me a lot of really like free wins, I will go for that. Just gonna admit that right now.
If there's an easy way, I'll do it, and CSS is often that. So the things that CSS are really great at when it comes to animation, are things with really well-defined state transitions. You know, things that you know exactly where it's coming from, exactly where it's going. So that's things like looping animations, loading animations, stuff that repeats, things on hover. And all those things, all those events that CSS has access to, which maybe I shouldn't say all those events because it is a short list, but that's okay. So examples are always better.
CSS is awesome at stuff like this, fancy effects on hover. This one even has like a blur, mmm.
Also, things like build-in animations, if you want things to just kind of show up in place, and kind of animate into place as they load, CSS is pretty awesome at that.
Notification animations, or if things, like with feedback that need to kind of repeat. I like this one, I'm like, oh, I have a message. I have a message again, I have a message again. (laughter) Or it's just looping.
And it's also really great at things like loading animations, I mean, you know, we see lots of pens and things like this, because CSS is really so great at this.
All of these examples so far have been really small, but CSS can totally do things that take up more space onscreen.
It can do awesome full-screen venue transitions, like this. Ooh, anything where you need just a hint of 3-D, CSS is like, oh hi, I can do that for you very easily. Which is like the best, you just wanna give it a hug. Or I do, anyways.
So the kind of the, I guess the pros of using CSS if you do use CSS for any of those things, is we don't need to have any external anything. CSS is just there, if you're making a thing on the web, you probably already have some CSS somewhere. So you can just add the animations to that. You don't need to create an extra thing, you don't have to have meetings about like, do we wanna download or add an extra request, do we wanna start using this extra tool? None of those things are necessarily required. And there's really a lot of potential for really good performance of CSS.
Notice that I'm not saying CSS is always more performant, because those kinds of absolutes are never true. But there is a lot of potential, or a lot of things you can get for free if you choose CSS, if it can do the things you need it to do.
Things like keyframes are reusable, so we can make CSS animation really modular.
You can write a set of keyframes, reuse it like 600 billion thousand times or so, and it's still one set of keyframes, and that's pretty darn cool.
And of course, we can even like adjust properties and media queries, so we can make CSS animation be responsive when we need them to be, in the exact same way we make the rest of our CSS responsive.
So there's a lot of kind of, just like easily fitting in things that CSS does.
For a lot of folks, too, I've talked to, some designers really love using CSS for animation, because they're allowed to touch it.
Some designers aren't allowed to touch the Javascript, but they're allowed to touch the CSS, they're like, ha-ha, animate all the things. So you know, depending on the tools you use and what you're doing, you know, CSS can be a good option on both those angles.
Another thing I wanted to point out is CSS animation and transition support is really, really great, but of course you know that.
The main thing I wanted to show this was, look at the lack of prefixes.
And here, too.
Alright, I was impressed with that, but fine, it's cool. (audience laughing) So there are some possible drawbacks to using CSS. It's very, like I said, not a lot of events that CSS has access to.
It's good at a few of them, not a whole bunch just on its own.
You have to know exactly what's gonna happen ahead of time, which sometimes is super easy.
Like all of those examples you saw, they were all like, you know, the navigation menu is going to be like, you know, zero opacity and really big up front, and then it's gonna go to being slightly smaller back in space, and being, you know, opacity of one. Those two states were totally defined.
You knew exactly where it was coming from and exactly where it was going.
Not every UI animation that you'll deal with, you can't say that for every single animation you might make, but if you can, CSS is gonna be a good option for it.
Currently, you can't separate properties on transforms, so things like scale, translate, rotate, they're all kind of cobbled up together in the transform property.
You can't really separate them right now.
There's a star there because you can behind a flag in Chrome Canary, which means you probably will be able to in the future.
But I guess you could add like a second one, 'cause CSS variables kinda let you do it, too. But for right now, it's not really an option. So, one good way to get around at least a few of those things, a few of those limitations, is to use CSS and Javascript together.
It's a pretty great way to get around things. And this happens probably a lot more than you might realise. For things, for example, like this, where this is kind of like slideshow-ish, sort of like hero animation, showing what this product does, and this whole thing is kind of running when like, you know, showing these different states, these different slides.
And all of the animations are being handled by CSS, but in the background, there's some Javascript that's kind of keeping track of the timing, and triggering these CSS animations when they need to happen.
It's like, alright, time to show this screen. Go ahead, do your thing, that thing's supposed to leave, go trigger the leaving animation.
It might even be called leaving, who knows? So it's a great way to like get the best of both worlds, have Javascript take care of that logic of like where in time should these be triggered, 'cause CSS certainly doesn't know that on its own, and then have CSS take care of all the actual animation bits.
This can happen on a smaller scale, too, where this is Medium, when you're like editing a Medium post and there's you know, this kind of pattern shows up a lot in other places, too, where once you click on this little plus icon, this other little menu of icons comes out.
You know, the whole quick event is handled by Javascript, which swaps some classes, or some other way triggers the CSS animation that has those all kind of like come on out and fade in, so it's a great way to use them together, as well. Apparently, this one I did not loop, so you only get to see it once, sorry.
But you can just imagine happening over and over again, it spins, and then these come out.
So, you're that, using them together to get that kind of best of both worlds can be something that's kind of like a, you know, a narrative sort of thing like the first example, or something that's very interactive and just, you know, used, triggered on events that CSS doesn't know about all on its own.
So the things that CSS are super, super awesomest at, because that's a word.
Animated interactions with defined states.
If you can say exactly where it's going, and exactly where it's gonna start, CSS will do that for you very well, which generally boils down to simple interactive animations, which isn't to say that that's like bad, because a lot of our, you know, a lot of the UI animations we create are pretty simple. We're going from this state to that state, and you're just like, CSS, do it, and it's like, got it. So it can be a pretty simple way to just get a lot done very quickly and very easily.
Of course, or the biggest kind of pros to using it is your, you know, those kind of performance wins, and the fact that you don't have to have any additional requests or any additional libraries, which is pretty handy.
So, CSS is pretty awesome.
But you definitely hit some limitations.
I wouldn't say very quickly, but there's like some definite places where you're like, ooh, CSS, you're making this a lot harder than it needs to be. So CSS is pretty great, but you might need Javascript if, I feel like I should add a dot com after this, I don't know. If you'll be chaining more than three animations in a sequence, which we sort of saw with that, kind of stripe hero animation, where they were like, they definitely had way more than three animations. They could have strung that all together with CSS animations, which would mean, they'd have to line up all their delays based on the duration of the animation before that. That's pretty cool, gets really old if you ever need to edit it, and you have like more than three or four, and you have to go change all of those delays, and all of those durations.
And even if you're using something like SAAS to maybe make that I little easier, it still gets old pretty fast.
I know, I've tried it.
If the animation needs to be dynamic in any way. If you don't know for sure that it's going to start here, and it's gonna go there, whatever those two states are. If those are not clearly defined, you're gonna have a lot of trouble getting CSS to do that in a really efficient way.
That's where Javascript does a lot better, because it can kind of know more of that logic than CSS does.
And if you need to animate, you know, transform properties separately.
There's some cases where you're just like, you know what, if I can't animate scale separately than transform, my life is going to be a nightmare.
And in that case, maybe it's time for some Javascript. So, as you might have guessed, that makes us heading over to Javascript island.
Which is my favourite island in the world.
It's so cute, there's mountains.
Anyways. (chuckles) So some things that Javascript are super great at, these more complex animated interactions.
Things that are more like narrative or immersive animations. If you think of like the generally very small animations we see that might be like on hover, on click, these things that happen on like buttons, or various UI elements, those are often the kind of invisible animations.
Like you want them to almost be unnoticeable. Like you want the person using your stuff to appreciate the sophistication and added information those bring, but you don't want them to be like, oh, that hover animation, great stuff.
It's not a thing you want them to say.
When it comes to things that are maybe a little bit more narrative, like you're trying to tell a specific story, or create kind of a more immersive environment, whether that's like a landing page or a game, there's a lot of different kind of immersive levels you might wanna do, and Javascript's great at that. And of course, these dynamic state transitions, as well. So some examples of that, 'cause examples are always better. You know, animations like this, where this menu has different widths and different heights, and those are going to different places.
They're not always starting and beginning at the same place. And then also, you know, as this menu, if it was for a site, or it is for a site rather. You know, if there's things that need to be added. What if there's more options later? You know, Javascript is gonna do a better job of letting you write animations that can adapt to that very easily, and doesn't care that they might change or get more items, or be bigger or smaller, or anything like that.
Also, for things that are more like drag and drop interactions, especially fancy drag and drop interactions, which this one is.
Like drag people in line.
And also like that super bouncy entrance, as well, is a little easier doing Javascript.
This is all, those whole thing is just like super fancy drag and drop animations.
So, you know, all that kind of thing, triggering those animations off that, and getting that interaction, definitely something Javascript can do really well.
You probably could make it happen in CSS, but I wouldn't wanna try it.
Also, when we have cases where multiple elements are kind of all feeding off the same input, which is the case of this 3-D lion.
Even if you don't have a 3-D lion, he's just the cutest example I could find of it. And when you have multiple elements all feeding off the same input, the same like, in this case, the where the mouse is moving around, and the very surprised happy lion is looking at it. You know, all the pieces of that lion's body. Having all those things kind of follow that same input, that same, you know, changing variable, is gonna be a lot easier in Javascript.
Also, things that kind of have multiple elements like moving on the same general like overall tic.
Like things like this little slideshow kind of thing here, where there's like, parts of the image move, the title moves a little bit.
And then that secondary thing comes up.
Like each one of these transitions sort of has its own rhythm, like there's a specific order all those things happen in, it's just acting on different stuff.
Sort of like, there's a really short timeline for each of those transitions between the different slides. And in that case, Javascript does a lot better job, as well, basically being able to keep track of, you know, all those different things and what's moving one. And really, also allow you to like author that more easily. Like it's not that you couldn't pull this off in CSS, it's just if you ever needed to edit it, Javascript solution's probably gonna serve you a heck of a lot better.
And of course, anything that's really properly 3-D, you're gonna need Javascript for.
And also these dynamic animations, where it's like, where is this line going, where is it starting? Every time it's different, it's gonna be much easier in Javascript.
I just love this glowy earth, like ohh, it's so pretty. So of course, if we're going to say we're going to use Javascript for a thing, the next question is always going to be, are you gonna use like Vanilla Javascript, or some kind of library? Good time for dessert metaphors.
I would totally eat either of these ice creams. They both look pretty good, depending on your mood. You might be like, I just want a basic vanilla cone, or maybe you might want a fancy sundae.
One is not necessarily better or worse than the other, but you do sort of have to make that call.
So if we're talking about vanilla Javascript, and when it comes to animation, the way we get that done is with request animation frame.
So that's our vanilla in this case.
And the request animation frame is really, I mean, it's the most performant way to get animation done with Javascript, you know, browsers essentially can update that, they tend to update as quickly as they can, based on like the browser itself and the hardware it's running on.
It also like stops running when it's not in the active tab. So many, many wins for using that.
And you know, we can write our own little animations with request animation frame.
For example, when to move a cat, 'cause I feel like that's the thing I do most with Javascripts, move a cat. (audience laughs) You don't? (chuckles) Weird, yeah, usually off the keyboard. (laughs) So if we wanted to move a cat with request animation frame, we would have a function called move cat.
And then we would have something that says how, something that needs to change per frame so we can like have something move and animate, because if nothing changes, nothing animates, and then this cat's not gonna move.
So we're basically like hey, our current value's gonna be this change in value times progress. Pretty easy math.
And then we would tell our cat, alright cat, take that current value and move yourself that many pixels. You know, in this case, we're just transforming it on the X-axis, and then we actually, you know, sign this request animation frame, and then we call the function.
So if we take that function and, you know, just add a little bit more math to figure out when it should start and when it should end so our cat doesn't just move forever and ever, we get something like this.
Cat totally moved.
And of course, I mean some of these variables are super long, but that's like a lot of code to make the cat move across the screen, and he's moving in like a linear fashion, which is fine, but I mean, he's in a spacesuit, so you could move with linear easing in space.
He wouldn't actually stop, though, but that's okay. Sorry, anyone who's into physics.
But chances are, you probably want your animation to have some sort of easing, you'd like it to like speed up and slow down.
So we didn't have any easing there, we'd need to add that. What if you had more than one cat? Or what if you wanted like the cat to move, and then some other things to move, and suddenly, this request animation frame animation starts getting a little bit complicated.
Not impossible, but a little bit complicated. And that's why people turn to things like Javascript animation libraries.
Not necessarily because, well, generally because they make our job easier, right? You could do everything that a Javascript animation library does yourself with vanilla Javascript and request animation frame, it's just probably not a way you want to spend all of your time.
But it's good to know that under the hood, that's pretty much what all of these animation libraries are doing.
Or I guess the better thing to call them is maybe animation engines.
I feel like we use the word library for too many things. But that's okay.
So, and these Javascript animation libraries come in like so many different sizes and flavours, just like ice cream.
Yeah, totally thought this metaphor through. You can get libraries that do everything from just provide you with a simple set of easing equations that you could use in your own request animation frame animations, to things that will cover like every possible animation task you could think of, like ever for the rest of time. So, I mean, I personally have some favourite Javascript animation libraries I use for projects, but I figured it wouldn't be super helpful to just tell you all to use what I use, 'cause like, where's the fun in that? So I thought I'd walk you through like, how I would pick an animation library if I was starting a brand new project today. If you were like Val, here's a project, you need to animate it.
And I'm like hmm, sounds like we'll need Javascript, 'cause there's a lot of dynamic animations, 'cause that's how I talk to clients, it's weird. (laughs) You know, this is the way I would go about figuring which one to use, 'cause there are just so many. I probably start with making a short list, which if I was gonna do that today, the three I would pick would probably be GreenSock, because it's been around forever and ever, seems pretty stable, I've used it before. A lot of people use it on CodePen, which is probably a good sign.
So I'd pick that as one of my three.
I'd probably also look at Velocity.
It's also been around for a while.
Not, doesn't get used, well, I mean like on CodePen and stuff, you don't see it as much, but you definitely see it, you know, like out in the wild.
And then, I would also, for the third one, maybe a bit of a wild card, pick Anime.js, because I've seen Marylou use it in a tonne of demos on Codrops, and it looks like it's pretty capable, so that might be one I'd look at, too.
So I made that short list kind of based on things I've read and looked at on the web.
I was originally, I wanted to try to make this list based on the ones that are most used in production. But pretty much every site you go to that's like, you know, showing you stats of library usage, if you go, if they have an animation section and you go to it, the top one is jQuery.
We are not gonna talk about that. (chuckles) I'm just like, it's like the Web is just skewed from all those old sites using jQuery.
So no, anyways, those are very helpful.
So, let's take a look at, oh first, before we look at what's different between all of those, let's look at what is similar. They all have a really similar syntax.
For example, this is GreenSock.
GreenSock has two different products underneath GreenSock, one called TweenMax, one called TweenLite, just to keep it confusing, I guess.
But they really all work in a very similar way. So for TweenMax, if you wanted to move a thing, you'd be like, hey TweenMax, can you take this box, and can you like make it's capacity like half, and then move it 800 pixels? Can you do that over one second, and just ease that with some Power2.easeIn? And it would be like, okay.
If we wanted to tell Velocity the same thing, we'd be like, hey Velocity, can you take this box, change the opacity, move it 800 pixels, take one second, and use the easing of easeInQuad? Which, these are actually the same easing.
GreenSock calls it Power2, everyone else calls it easeInQuad.
Everyone else is with the Penner easing equation names, but GreenSock isn't, that's okay, same curve. And if we want to do with anime.
This is, you probably already saw this coming. You'd be like, hey anime, can you take this box, make it half its opacity, and move it 800 pixels over, over one second, using easeInQuad? Whoo, long sentence to say out loud, but really, really similar in their syntax and how, you know, how they function in that way. Taking an object, making it move, good stuff. So a few other things I would look at to compare or contrast the three, are a few factors like these.
For example, size of the library.
GreenSock has a variable size, depending on what you wanna use, they have like different versions of it you can use, and it can be anywhere between like seven kilobytes and 29, depending on which bits you wanna use.
Velocity just has one version, which is, you know, that's, you use it or you don't kind of thing. And Anime is a whole lot smaller there at 4.7, which is interesting.
But you probably wanna also look at browser support, I hear that's a thing we care about.
You know.
GreenSock goes all the way back to IE6, which is kind of crazy, who's had to think about IE6 recently? Hopefully, none of you.
Velocity goes back to IE8, and Anime's only back to IE10. Now, for the people who are like going to a Javascript pub quiz later tonight, you might remember that request animation frame is only supported in IE10 and above.
So obviously, Velocity and GreenSock are doing something to, kind of like as a fallback for request animation frame under the hood for those older browsers, where Anime isn't. Maybe that matters to you, maybe it doesn't. Depends on the browser support you need.
What I always like to know, when I'm trying to use a new thing if there's gonna be someplace I can go for help, when it's, you know, maybe late at night, and I don't know the answer to how to make a thing happen. Not that you've ever been in that position, but if I was, I look for those kinds of things. So GreenSock has documentation, it also has forums. Velocity has documents, and there's a lot of, or documentation, and there's also a lot of questions on Stack Overflow about it, so that's pretty good, too. Anime is pretty new, so it really only has its own documentation, it's not the end of the world, but you know, maybe a little bit less in the way of help available there, probably because it's newer. And then I also probably look at some special features that each of them might have.
For example, GreenSock has a lot of fancy SVG things, like drawSVG, morphSVG, and then Draggable, which doesn't say SVG at the end, which I think they really missed a thing there. Or it has nothing to do with SVG.
Velocity, its kind of main thing is, it's a drop-in replacement for jQuery, if you've been using jQuery, and you're like realise it's not doing the things you need it to do, you can just pop Velocity in and it's like, yeah! That's exactly how it works.
And Anime's probably biggest thing is it's super, super lightweight, I think that's its biggest selling point. I would also look at licencing, and what kind of cost there might be involved. GreenSock does have some paid licencing requirements for certain kinds of ways you might distribute it in a product or anything like that.
It's not fully open source in that sense.
Velocity and Anime are both open source under the MIT licence, so that can make a difference in how you choose them, too.
But, you know, there's a lot of different factors, and despite how much these have in common, they all kind of approach things in a slightly different way and have slightly different features.
So depending on what you need, you know, one might be a better choice for you or a more appropriate choice for you than the others, and of course, there's more than three of them out there. So where Javascript shines.
Complex animations, obviously, things with dynamic states. Immersive animations, anything that you like really are gonna have a tonne of animation going on, and would like to control that animation in some sort of central way, Javascript is your pal. Probably one of the biggest pros about it is just how many options there are to get it done.
You know, we looked at three different libraries. Great, awesome, there's totally more than two. And of course, you know, when you're using Javascript, you can animate like literally anything in a browser, it's kind of cool, you're like, DOM elements, got it. SVG, totally, canvas, sure, WebGL, all the things. That should be the new tagline for Javascript. (audience laughing) Anyways, this might be why I don't get asked to do taglines. Hmm, while we're on the topic of Javascript, I'm gonna talk a bit about, wanna take a little detour into React land, not as like an endorsement that I think you should all be making stuff in React, but I hear it's a popular one, it's come up a couple times today.
You might've noticed.
And also because, if you like ask the Internet, hey Internet, what should I use to animate in React? It will give you somewhere around like 50 thousand billion answers, and you're like, what am I, I just need to get a thing done.
And the Internet's like, yeah, sure, whatever. So, there's a couple things I wanna point out about animating in React.
The first one is, you can totally use the stuff you already use to animate other things, it's so true. Just because React, you know, is a framework, it does its thing the way it does its stuff, they're, you know, the things you run to write a React component end up in the real DOM eventually when they're actually rendered out. So if, once they're in the real DOM, we can use things like CSS and Javascript to animate them, crazy. Or at least I thought it was.
So you can totally use things like CSS Animation with React together, without doing anything super fancy. If, for example, you had some CSS like this, somewhere in your project, whether you read it, in whatever you wanna do, we've covered a lot of different ways to write CSS today.
There's just some keyframes, and then if anything with the class of drop shows up in the DOM ever, it's gonna animate those, pretty fun.
And CSS doesn't care if there's never anything with a class of drop, it doesn't mind.
It's just gonna hand out and wait.
Then when something with drop shows up in the DOM, perhaps rendered out through a React component, it's like, got it, go, and it makes the raindrops drop. (chuckles) Yeah, my naming conventions for animations are pretty amazing.
But you know, it's a pretty simple way for things like, things that are maybe more decorative, like icons, or ambient animation, you don't have to go through a whole bunch of hoops to make them animate, even if they're being rendered out by React. React, you can also use React with the Javascript libraries we looked at in our last sort of like decision section. I just, really creating a reference to a thing that's going to be rendered out.
In this case, we're like, hey, can you save a reference to this scene? And React is like, okay, I guess so.
Then when we actually know that that component did mount, and we know the component is being rendered out into our actual DOM, we can be like, hey, scene, remember us? We would like access to your children.
Which actually sounds really creepy when you say that out loud. (all laughing) Did not realise that until just now.
But then we can take the children. (all laughing) Just gonna go with it.
Point GreenSock at them, and be like hey, could you stagger the children from this point to this point using this kind of staggered animation? So we can use these Javascript libraries without like adding a bunch of extra things, we can just have the library, have React, and just by essentially letting, you know, being aware of when those things enter the real DOM, we can use things that we would be using for non-React projects, too, so that's pretty fun. Oh, and then the result of this, super amazing. 3-D flipping children, yeah! So, there are also more reacting ways to animate in React, 'cause that is also a word.
And these are the ones you usually find when you Google, how do I animate a thing in React? I feel like there's one major warning about the Google searches for how to animate in React. I feel like somewhere around like 80 to 90% of the results you're gonna get, are gonna tell you to use React CSS transition group, please don't. It's really one of the hardest ways to animate in React. It's also kind of being deprecated.
But to find the information that it's not really the best way to animate in React, you have to read a lot of GitHub comments, it's just, for some reason, all those results end up at the top of Google, even though it's maybe not the best way to animate in React anymore.
If you, you know, or at least not something to start out brand new.
There are, there is also the React transition group, which is a little bit better.
Gives you like maybe lower level access in a way, and let's you kind of make those decisions for yourself. And then there's also a thing made not by React people, but by another developer whose name completely escapes me right now, called React Transition Group Plus. Which, do you notice a pattern to these names? (chuckles) This one is great, though, because I feel like 90% of the time, the reason you might turn to React Transition Group or React CSS Transition Group is because you want something to leave and something to come in.
And you'd like them to like animate in and animate out in a logical way, and in React, and Transition Group Plus has built-in ways to do that. They're just like, I should maybe play the demo video, that'd help.
They're like, do you wanna animate a thing in? Do you wanna animate it in and out? How would you like them to interact, there you go. It even works on not squares. (audience chuckles) So, pretty handy one to look at if you need to like animate components coming in and out as they appear or get removed.
React Motion is also an option for animating in React, much easier name to say, thank goodness.
But React Motion is all springs, which is great if you need springs, if you need that like kind of super bouncy physics, perfect for that. But, you know, springs aren't necessarily always what you want for UI animation.
Sometimes they're great.
You know, there's definitely some of the examples we looked at could use springs, a lot of them didn't. Springs are really great for being super responsive, and the fact that you give some kind of input, and they're like, yeah.
And they don't care where they're going, they just do their thing and spring around. They're awesome for that.
But if you need to like chain animations together, springs become not so great, because many of the times, spring animations look like they've finished before they've mathematically actually finished. So you may be like, you go, then you go.
And this animation be like, you look like you're done, why aren't you going? And it's like, 'cause the math says he's not done. So, my code talks to me a lot, it's really weird. But yeah, so springs are awesome and great, React Motion does springs.
But you kind of only wanna use it if you actually need springs or want springs.
One other thing about React is they've recently, I guess, released or pre-released Fibre, which is really gonna change the way animation works in React.
Lin Clark did a really great talk all about Fibre, and how it's going to work, and how it's going to change, how it's gonna change animation things.
So her talk on that is super awesome.
Alright, that concludes our time on Javascript island. I hope you enjoyed it.
So let's talk about some SVG, yeah.
SVG is like my most favourite, really.
(audience laughing) I mean, it's so cool.
But this why, though, 'cause like, this is an SVG, this is the same SVG.
It's like this, and it's like that, same thing! This is the number-y version, this is like the display version, I guess.
The fact that SVG is like actual objects in a thing, described with math, amazing.
Alright, just to me, that's cool, whatever. (audience chuckling) But this is what makes them so powerful.
Like these are visual things, they're images. But they're actually also objects that are there in the SVG, that we can like totally mess around with and animate.
So that makes SVG super great at anything that's like an animated illustration.
Animated icons, that kind of thing, for an example, a cloud that's raining, pick for, let's say. Infographics and dataviz also get used, SVG gets used for them a lot, mostly because, in a way, they kind of are illustrations, and also because they are real objects.
There's, you know, there's an object in the SVG to represent your data, it's so cool.
And anything that needs to be like really fluidly scaling and responsive, you know, when it comes to, you know, we can adjust our CSS and Javascript animations based on media queries or however we wanna do it. But SVG by their vector nature, you could just be like, just scale, and it's like, okay, do you want me to be this big or this big? I don't care, I'm good.
And that factor allows people like Bustle to make these really cool flowcharts, where this is like just one SVG, but they're like, let's do a quiz and zoom into parts of the SVG, yeah. And they can go through this whole thing, because it's one big image, and they're essentially kind of like moving the SVG viewbox as a camera, to be like, let's go over here, let's go over there, what's your answer to this one? And the fact that they've done these in SVG means they can make them be a full-page thing like this, or they can also make them like really tiny half-page things, like they can make them be any size. They will still be fully interactive and animated, and all those things, but they will just scale, because they're SVG, which is awesome.
SVG is also great for logo animations.
If you're ever in a meeting, and someone's like, maybe we should animate the logo.
Before they finish that sentence, just yell SVG at them. Just like, SVG! And they'll be like, what? (chuckling) But generally, if there is a logo or an icon that needs to be animated, you wanna turn to SVG for that. And also, anything that involves shape morphing. Anything that needs to take one shape, turn it into another, because SVGs are shapes described in math, they're great at that.
So things like this.
As a random aside, I'm like, why did we go for the hamburger menu when we could have had the pizza menu? (audience laughing) I just, I mean, I'm so disappointed.
SVGs are also really great when you're doing any kind of like narrative type of animation or, you know, a lot of things, you know, you might think of that as being like comics and storytelling and all that stuff, but it also really comes in handy for things like onboarding, when you're like hey, here's how our product works.
You go on a little journey and then stuff happens. That's my summary of every onboarding situation, sorry. (chuckling) But you know, you've got those little kind of little mini-stories, little mini-steps, and SVGs a great choice for these kinds of things that need to sort of demonstrate, either conceptually or like actually, how a thing works. Perfect way to have these nice little contained things. And then essentially, anything that is squishy, which is like this entire site.
Pretty fun, it gets squishier.
Yeah.
If it's squishy, SVG, if anyone says squishy in a meeting, just yell SVG at them, and hope they were talking about, you know, work. (laughing) Like this muffin is squishy, like SVG! Nah, that would not work.
Anyways. (chuckling) This might be why I work in a very small team. (audience chuckling) So, when it comes to SVG, we get one level deeper in our "it depends" because SVG can be animated three different ways.
Because why would we have one option when we can have three.
SVG can be animated with smile, or S-M-I-L, however you like to say it.
I like calling it smile, 'cause I like to imagine it being very happy.
SMIL is tag-based animation that actually happens within an SVG.
Have you ever opened up an SVG, and there's little tags that are like, actually say like animation and animate? That's SMIL going on.
It's very powerful, but unfortunately, it has no IE or Edge support, and it's being deprecated in Chrome, so I'd suggest maybe not, if you don't already use or know SMIL, maybe don't, this isn't a good time to learn it.
It is gonna be on its way out though, slowly in, not like tomorrow or anything.
So, I know a lot of folks who work in e-learning are still using it, that's totally fine.
But you probably want to look for some other options if you wanna animate SVGs in a more like future-looking kind of way.
CSS can animate SVG, which I think is so crazy! CSS, it's just CSS and it can animate SVG, it can like, actual objects in an SVG, so cool.
At least to me, it's alright.
So CSS, you can actually apply transitions and keyframe animations, or transitions and keyframe animations to SVG objects, like even the objects inside an SVG, not just the image itself, which is pretty awesome.
You are limited to the number of properties you can access with CSS, but that's not a limitation of CSS, that's just because SVG 1.2, or whichever one we're currently at, doesn't, only exposes so many properties to CSS. It's kind of like, these are all the things I can do, and CSS, you may have access to this small portion. Most of those properties are all around fill and stroke, which is actually pretty handy for many effects. And we can also apply CSS transforms to SVG elements, except in IE or Edge.
Which makes it a little bit limited, but also, a lot of times, if you're just animating some icons, or something like that, you kinda don't care if they don't animate in certain browsers.
You know, like Charlotte was saying, things don't need to like exactly the same in every browser, and if your icons only animate in browsers that aren't IE or Edge, does that matter? Maybe it doesn't, maybe it does.
So CSS gets a little bit of a smiley.
And as you probably guessed was coming next, SVG can also be animated with Javascript.
And Javascript can essentially do every single thing that SMIL can do, probably for this more complex stuff, you'll want to employ a Javascript library, unless you like writing really hard code by yourself without some help, but that's okay. You can do things like motion along a path, shape morphing, all of those things.
Actually, all the examples we looked at with the shape morphing, we didn't have any motion along a path, but all the shape morphing was actually done with Javascript in those examples.
So Javascript is a pretty good option for animating SVG. Pretty much, if you wanna do something beyond just like a, you know, simple icons with, simple animated icons with SVG, you probably wanna get some Javascript library, animation library going, just to like open up your options and make your life easier. So one other thing I wanted to point out about SVG is it has like so much great support.
SVG is like green in all the places.
Which means, any browser support limitations on your SVG animation is not a result of your SVG, it's a result of what animation technology you pick. So, you know, SMIL is gonna have its browser limitations, CSS has its browser limitations.
Javascript kinda doesn't have any limitations, but that's okay.
You know, it's really not SVG that's making animations not work in certain browsers, it's what you've chosen to animate with, 'cause SVG has got some crazy good support, go SVG.
SVG also tends to be used on very visual things, and if you like to work with them in a visual way, there are libraries like bodymovin, that will let you take After Effects animations and export them to SVG.
Also to canvas as well, but SVG is like totally cooler. There's also from, some tools that Airbnb made like Lottie, that kind of builds on top of bodymovin, and lets you export After Effects animations both for, you know, like React Native, Android, iOS, all the things, so it goes even beyond just SVG to all these other platforms, which is pretty handy. And also, I don't believe Airbnb is behind lottiefiles, but someone else is, and they've basically made this site which is a collection of Lottie files that people have shared for anyone else to use.
So if you wanna take a look at what those Lottie files export and how they work, they've got example animations for all the platforms it exports to.
So lots of ways to get some like visual access to these SVG animations, as well.
So SVG, super awesome for illustrations and infographics. Anything that involves morphing shapes.
Anything that involves like motion along a path. SVG's probably gonna be your best bet right now. The biggest, coolest thing about them is how responsive they are, and just how tiny some of these file sizes are.
I mean, SVGs can be so small, and then you can just, you know, you can get a lot done in this tiny, tiny file size, so it's pretty nice in that kind of, in that sense.
Which kind of leads me to performance, which is the water that connects all of the web animation land.
I don't know, I was trying to think of a good metaphor, that sort of worked.
You know, no matter which tool you're choosing, you're going to be concerned about performance, I hear it's a thing.
You may have heard that, if you animate things like size, position, and rotation with transforms, or opacity, that you're gonna have much more performant animation than you would doing other properties. And that is actually totally true.
Conveniently, even though it's a list of only four things, those are the four things that pretty much any visual effect requires.
Like if you talk to someone who does a lot of motion graphics work, and you were like, what did you use to make that effect happen, they'd probably be like, I animated the position, size, and rotation.
You know, if they, the main building blocks of just about every kind of animation, and they're the ones that happen to be the most performant, so that's pretty handy. If you were wondering why, the simple, I guess, or the quick explanation as to why, is because of the way browsers actually render things to the browser window, the way they sort of update these things as we go, which happens a lot when you're animating, because new things are happening and changing. So, generally, something happens to trigger a change, whether it's page loading, some sort of event, whatever. A thing happens, and the browser's like okay, let's take a look at what CSS rules should be, what applies to this change, what's gonna happen? What sort of styles should be changed? You know, which elements are affected here? And it figures that out, and it's like alright, now that I know what's gonna be affected, what kind of layout changes might I have to make? Like is this gonna be a lot of layout changes, just one, or is a bunch of things changing size, is one thing changing size, what are we looking at? Then, after layout stuff, the browser moves on to actually paint the pixels onto the browser window, which I like to imagine a little like artists, just being like one pixel at a time, it's pretty fun. And then the very last step is moving all of those things into the appropriate layers, you know, once they've been painted, which layers should they go on. That's like the composite operations.
So, all of these things, you know, generally happen in order, they start from the beginning, but you don't have to hit every step along the way. Paint is the most expensive, obviously, because it does take so much effort.
But if you have, if you're animating properties that only need to update on the composite step, you never hit that paint, and you get a little, you get more performant animation.
So if you're wondering what properties, or what steps rather, various CSS properties hit, there is an awesome site called csstriggers, which you can search for any CSS property and will tell you exactly which one of those steps it hits in like every browser that there is. Even based on changing by default or subsequent update, it's a pretty detailed site by Paul Lewis.
So that's very handy.
Great to know if you do need to animate things that aren't on that list, of what, you know, what sort of things you might be impacting. There's a couple of really easy ways to tell if you have hardware-accelerated animation, if you are getting that just composite layer animation action.
There's tonnes of things you can do digging into like the browser, the dev tools and the network tab and everything, but there's also a really easy way. You could just like turn on paint flashing. In this case, the orange box is animating margin, aqua box is animating a translate, and then you're like, let's turn that on, and our margin one gets a big green square. Conveniently, while playing this, also the margin one is kind of stuttery, but that doesn't always happen, so obviously, especially when there's only two things. But that's a quick way to check if you've got hardware acceleration going on in Chrome.
And Firefox even gives you an easier way to tell, in its animation tab in its dev tools, there is this little lightning bolt that happens, and even there, if you've got things that are hardware accelerated, it's like good job, lightning bolt for you.
And if you're in a situation where something could be hardware accelerated but it's not, it'll give you this little tip of like, hey, this could have been hardware accelerated but it's not, because this stuff is happening.
So it can be a nice way to dig into your animation performance that way, I think it's pretty handy. I'm always like, do I have lightning bolts? Uh, it's very important.
So, when it comes to performance, here's how all these things compare.
Your CSS is declarative, like we talked about at the very beginning, when you know exactly where you're coming from and exactly where you're going, it's all spelled out ahead of time, so that your chances for good performance are pretty good, because the browser knows exactly what's going to happen. When you animate with those particular properties, you're going to, you know, you're gonna have much better performance than if you're like animating top and left and margin and all of those things. And CSS animation won't be impacted by the main Javascript thread of logic, which is why it's used for loaders a lot, because you're like, there's stuff happening, we'll just animate with CSS so that it won't get all weird and staggery. Javascript, you know, the browser really only knows what's happening one frame at a time.
If you remember back to when we were moving the cat, you know, we had that function that was just like, just add a few pixels each frame, and the browser's like, okay.
And that's kind of all it knows, so, you know, that's why it takes a little bit more work to get that performance.
Hardware acceleration isn't automatic.
That doesn't mean it can't happen, you basically just have to ask for it.
You know, whether, if with CSS if you're animating transforms, you'll probably just get it. With Javascript, you have to do something, either like do a null translate, or use will change or something to be like, hey browser, hardware accelerate this, please.
Of course, that gets, that can get pretty complex as well, but you have to ask for it, essentially.
If you're wondering about SVG, SVG and hardware acceleration is not as good of a story.
Not all browsers support it.
Recently I was saying that no browsers supported it, but then someone from Firefox was like, we do. So Firefox hardware accelerates SVG, most other browsers don't.
There is generally some sort of like bug reports and requests for it, though.
SVG generally does get pretty good performance, even without being able to be hardware accelerated, I think just because the file size is so tiny. So even on mobile and stuff, you generally see pretty good performance, even though you can't force that hardware acceleration.
So, that was our little tour of the land of web animation. I hope you enjoyed our visit. (chuckles) And hopefully next time you face this question of like what you should animate, what you should use to animate a thing, you'll be like way more prepared, and know exactly what to use and what to turn to. If interface animation is a thing you are into, I wrote a book about it.
It's called Designing Interface Animation.
You can get a little discount on it with my name, and there's also a lot of pictures of my dog in it. Those are just three, but there's more.
So. (chuckles) I also run a little newsletter, talking about this stuff every week.
If you want sometime to remind you that animation is cool, every Friday, I can be that person for you. I'm always happy to talk about this on Twitter, so if you have any questions later next week or anything, feel free to hit me up.
Thanks so much for listening.
(applause) (bright electronic music)