 My name is Arun, I also do animation and drawing outside of work, so there's a topic that interests me. For the next 15 minutes, we'll talk about DOM animations. What is animation? You have a string of images, one after the other with incremental changes. You play one after the other in rapid succession, gives you the illusion of motion. Here you see a dog running. You shoot a video on your iPhone, it plays back, iPhone 6, the HD mode, it plays back at 60 FPS. Most videos that you see on YouTube run at 30 FPS. This animation here, before we go there, movies, 24 frames per second. This one is actually running at 10 frames per second. It still does its job. You still get the illusion of motion, but is it smooth enough? When you have something playing at 10 frames per second, this is what happens in a timeline of one second. You have 10 frames and that's about 100 milliseconds gap between each frame. That's fine. That's how the artist drew it and that's how we intend it to be played back. But your phone screen, though, puts 60 frames a second, it refreshes the screen at 60 hertz. You've got like six frames in what you currently, for that animation, you played just one. You could have six frames. So the increments could be smaller and hence the motion could have been smoother. So instead of 100 milliseconds, what if you had just 16 milliseconds for each frame, the distance between each frame? So this is the holy grail of all animations to make it smooth and all that. So this is what we'll be trying to achieve. So before we go there, let's just see if we can spot the difference between 60 frames per second and 30 frames per second. You can open this URL on your phone. It should get something like this. So it's tinyurl.com slash meta dom dom. So you will get something like this. I'll just show it here. It's a single div that just has a lot of fancy CSS to it and it's just bouncing around. So let me quickly toggle this to 30 frames per second. Tell me, you can tell the difference. Do you guys see a difference? That's 30. This is 60. So we'll also confirm that. You have this option in Chrome Tools where you can say, it's a bit dark, so it's kind of showing 60 there. That line, it's red on black, it's horrible, but it's kind of showing 60. I toggle it back, 30 frames, it drops to half. I purposely skip alternate frames and it drops to 30 and you still have it moving. Some of you might feel this is not good enough. And that's why we go for 60. On some of your phones, if it's really old, like mine, I have a Moto G here. It might be really struggling with this, so you could just remove all the CSS, put some simple CSS and see how it works on your phone. So if it's on your phone, you can try it out and you can actually decide if 60 FPS is really worth it for putting in the extra effort. So having said that, let's see what happens in every rendering. So we'll just record this for a bit and play it back. I hope it's readable. So for each animation frame, we have the script running. So the script part is where you can decide how much of it the ball should increment for each frame. Has it crossed the bounds? If it crossed the bounds, it should turn back and all that logic goes there. Next is once you've done that and you put a particular style on the DOM element, then there's the whole recalculation of the styles for the entire page and the layouts. One element changes, the layout changes for the whole page. You can update the tree and change the layout. And once the browser is done, it actually renders it on the screen. So there are three different things that happens. And all this has to happen in 16 milliseconds. So this is the same bouncing ball done on my laptop and on my Moto G phone. You can see the amount of difference in one second, how much time is spent in each one of these portions. So you can see painting actually taking up five, six times more time on my phone than it does here. How do you figure this out? We saw on the desktop, we do this. For the phone, you just go Chrome, inspect devices. And then you say, this is for a different page, but I'll just show you interest of time, inspect it. And now we're actually inspecting the phone. There's another page running there. So you'll see different things here. But you just run the same thing on the phone. And you can inspect it remotely. Using this Chrome inspect devices, it shows you all the browsers that are open. And the page is there. And then you can just inspect it. But the difference is kind of this. So you're seeing a five factor downgrade. But it's not like this is the deal. I mean, depending on the page, depending on the phone, this factor is going to change each time. But then you cannot go tell your users, see, mobile is restricted, so we cannot give you smooth animations. They're not going to listen to you. They want the mobile experience. And you know what that means, right? I mean, because the real estate is really small, the designers put in all these fancy animations to keep the users interested. Also, the user is actually touching the screen. So they get instant feedback. It's not like the mouse, where you're doing, moving somewhere else and the pointer somewhere else. So you get instant feedback. So all that kind of tends to put greater expectations on mobile UX than desktop in some cases. So we saw the three major parts. We'll just go through each one of them. First is request animation frame. The concept is that the browser is kind of rendering the screens at 60 frames per second. So we cannot give them a chunk of code, give the browser a chunk of code, and saying, the next time you start rendering a frame, can you please run this code? So you can see the small diagram that might represent what the browser is doing. It's going to render that. Vertical lines are each frame render start. It lasts for 16 milliseconds, considering it's 60 FPS. And then it goes on and on. So once you drop that chunk of code, those three things, script layout and painting, happen within that. Ideally, it doesn't happen as soon as the browser starts rendering the frame. You might see something like this, but that's OK. Now, I could do the same thing with setInterval and kind of run a chunk of code every 16 milliseconds. But then the problem is this. If the setInterval is triggered at some point in middle of the frame rendering, it'll actually kind of push itself into the next frame. So the browser has already started rendering the next frame. So it'll obviously lead to dropping off frames. I'll just try to do that. I'll have to be really lucky for it to work proper, because things like this happen. OK, I'm screwed. All right. So yeah, OK. It's back now. Yeah, so it's running at 60. Are you guys able to see the number in the frame counter? In that black box, there's red text in there. Yeah, it's kind of unfortunate. But if I kind of use a setInterval, you can see lots of frames being dropped. Some of you at the front can probably see it. So this is exactly the problem that we kind of illustrated there. So if you kind of reset it, you should see going back to a smooth line, because we use the request animation frame. Next is handleEvans judicially. Yeah, of course, as you move your finger on the screen, it is kind of triggering those events. Do you want to handle H in every event, or do you want to kind of skip a couple, and then move the object to the finger a little after every two frames? So those are the things you could do, because you don't have to run heavy code for each frame. Next, things like garbage collection can also affect your frame rate. So everything affects your frame rates, really. A simple check here. So I'll just reset this, and I load some obscene number of objects into an array here, and I click load object. And you can see it actually freezes for a moment. Let's actually record this, and see. Sorry. Got a timeline cleared. So I'll record this. Let's load some insane number of objects. Let's do it again. You can see the animation kind of freezing. Each time we do that, we clear the objects, load it again, clear the objects. So it's kind of to show that anything you do in your JavaScript kind of affects your animation. So you have to be really, if you're animating stuff, at least for the portion, when you're animating things in the page, just be really careful. You can see those towers there, heavy scripting. So you can see those shooting well up about 30 frames per second. And you can probably also see the entire memory here as it shoots up. The blue line here kind of shows increasing. So these are the things that can affect your animation. Of course, this is exaggerated. You're not going to load or do things like this, but this is just to exaggerate to show it to you. This is a simple code for request animation frame. You can look it up. I'm not going to spend time there. Next is the layout part. Now the scripting is done. You set the styles. Now the browser has to recalculate the styles and redo the layout. This is where you have to be careful of something called downtrashing. It's when you actually read, write, read, write alternatively. So this is a problem because every time you write, the browser has to recalculate the style before it does the next read. So because the last try kind of invalidates what it already knows about the positioning and the styles of the different elements. So this is a problem that we'll just check here how it works. So I'll start actually one second. OK, I'll just click this trash drum, and then I'll record this for a bit. Yes, it does something look out there because recalculate style is there. But instead of this timer, again, you have this recalculate style, recalculate style happening more than once for each frame render. And that's the downtrashing. And this really affects the rate at which you're going to render your frames. It's so obvious that the Chrome tools actually put the exclamation mark there saying you're doing something wrong here. So that's something you can catch easily, but you just have to be aware that these things can happen. So the other thing is that if the DOM is heavy or if the tree is really deep, it's going to be slow. We all know that the DOM engine is usually not a black stallion with shining skin. It's a donkey there. And the more you load, it's going to crash. Yes? So it's not just animation, of course. It's for anything that's there in the web page, any DOM manipulation you do. Heavy of the DOM, your application is going to suffer. The next thing that we're going to see is the paints. Paints are expensive, paint less, as simple as that. So this is a common design pattern that you see in mobile is where you add a header up there and keep it fixed, and added a scroll bar so you can show it to you. Now there's this option where you can see paint rectangles, right? So it puts a green box around whatever is being painted. Even if I move the scroll, it's going to paint the scroll again. It's painting this little guy here. All that is fine. But what we don't want is that you can see this whole page flickering, apart from these two guys. That's what you don't want, because this guy is not really changing. So why is this guy being repainted again? It's because it's fixed. It doesn't move, and it gets stuck in the page, and the browser thinks, OK, I have to repaint the whole thing, because something is moved there, and I have to repaint. So you can do that by adding a hint. So what it really does is it adds translate 3D to the title, and we also added a will change to this guy. Yeah, will change left. So to the country ball, we kind of said the left is going to change. We're telling the browser upfront left is going to change, and to the header, we said we're adding a transform, so it's likely to change. So the browser kind of puts separate layers on them. So the next time you do this, you don't see a paintboxes around the ball or on the header. So what really happens is, I don't know if the orange lines are visible here to the guys there, but I can see it here, and you can also see it if you try it on your browser, is that it puts separate layers for each one of these, and it composites at the end, and it doesn't paint explicitly each one of those. So that way you can do this. So it doesn't mean that you put everything in a layer. Composting also takes time, so you have to be really judicious about what you want to do. How do you do CSS animations? Translate transforms. The key is to keep the animations to the transform, translate, rotate, scale, opacity. These are really cheap animations that will work great. If you just do this, you'll have absolutely no problems. But you can't use CSS animations for everything. Wherever there's interaction, depending on the scroll position of the page, something has to happen, or depending on where you want to follow, where the person has touched, the user has touched the screen, you have to figure out where and where. All these interactions you need JavaScript animations, you could consider libraries like Velocity and Green Sock. So just to finish it off, be aware of the 16 milliseconds limit. Actually, target 10, because there are other things happening in the browsers as well. Use cheap CSS transform whenever possible. That's translate, rotate, opacity, and scale. More animation is not always necessary. It doesn't mean it's cooler if you use a lot of animations. Everything affects your frame rates. If your phone is a really hot place, the processes are not 100%, your animation is going to go down. And learn some animation physics, because just like perceived performance with some knowledge of how animation works, how things move, you can kind of give a perceived feeling of smoothness. There are some references here. So I'll stop here. I'll just do a quick show on the phone. This is not my code. It's written by someone called Arya. I just picked up Geek Hub, but it kind of uses JavaScript to kind of show us. Yeah, OK. So I'll just try to focus at this. Yeah, so this uses all CSS transforms. But you can see the amount of smoothness that you get. So all these are separate layers. And all this is done purely by applying transforms on each one of those separate. So each one of them are separate layers. So you can see you can achieve quite a decent amount of smoothness and nice animation field to even web pages. Yeah. Yeah. Once we have this, we can then comfortably say that we don't need the apps. So yeah, so that's it. So I think once the browser is always getting better, as the performance gets better, and you also kind of be aware of what is good and what's not good, I think we can get that at a stage where we can match apps in terms of the coolness. Thank you.