 We should talk about the web. We should talk about the web. And I have plans for the web. Ooh. Ooh. So I wrote a blog post. Good. Good start. I did not squeeze into a tweet, even though we have twice as many characters now. I need a little more explanation. And I was the entire event that sparked this interest is a colleague telling me that there's iPad Pros, and that is iPad Pros, run at 120 hertz. 100, that's double the normal number. 60 times 2. So yeah, most devices that we have worked with so far run at 60 frames a second or at 60 hertz. Right, because I remember in the days of SCRT monitors, you used to get quite a variance of. Yeah, it went to 24 hertz, 30, 50, 60. Yeah, I mean, for a computer monitor, you would tend to run at 60, 75, 100 late. Oh, yeah, right. Because the higher the refresh rate, the less. Flickr. Yeah, the less iPad it was. On the scale of 0 to iPad. It's like, how long can you watch it before your tears of blood, that sort of thing. But then once the CRTs went away, everything just 60. 60 across the board. Laptops, TVs can do it differently. They want to synchronize the frame rates. We call it also 24. 60 is a multiple of 24, which is something that's an issue. Right. And Americans TV run at 50. American TV runs at 60. European runs at 50. European runs at 50. Why? Just look, sorry. Just allow me to remove my screen. I think I just tapped into your specialty. I've really, I've done a lot. I did a bit about this in a talk a few years ago. And so I did a lot of research into it. Yeah, it was all based around the power frequency. Yeah, exactly. It could sync using the waveform of the power supply. So 50 hertz here, 50 hertz in a lot of Europe, 60 hertz in America, and a lot of other places, I think. But yes, we all decided, as often happens, we'll just go, oh, we'll go with the American thing, whatever. I mean, 60 sounds better than 50, whatever will do that. Why won't we take something that is a nice part of 100? Let's go with 60. And here's the thing. If we went with 50, if we went with 50, we would all have more time on our frame budgets, right? Yes. A significant amount of time longer to get a frame together. Yeah. But before milliseconds more. Exactly. But that's not the case. That's not the case. So, and that's the thing, like everything has been 60. But now we're going to have even less time. Well, kind of, yes. If you want to make use of the 120 hertz, yes. But the problem is that because every device has been running at 60, 60 has somewhat become an implicit assumption. Right. So there is a good amount of code out there that doesn't actually consider how much time has elapsed since the last frame. Who would write such code? I don't know, Jake, who would write such code? So, yes. So on Twitter, we were talking about this. Because this was from an Apple engineer. So the thing is, I looked at the iPad Pros and looked at 120 hertz. And I was like, this is amazing. This looks so good. It actually makes a difference, which I was honestly a bit surprised by. I was dubious whether you could notice a difference, but yeah, you can. It doesn't make sense because if you think about, you have 60 frames a second, especially with fast motions. You have more in-between images which will make motion blur seem much more real. Yes. Instead of having like three individual pictures from A to B, you will have now six. Yes, absolutely. Yeah, double that. And it makes more, your brain will think even more. It's an actual motion. And so I was asking, what's the plan, like your wrath on the iPad still runs at 60? Request an animation frame, my assumption would be, you would get a request animation frame 120 times a second. And you do not. And you do not. You get 60. You get 60. And that made me sad. Because that basically meant whenever you were using a animation framework that does the JavaScript animation with JavaScript, which I think at least parts of Greensock, for example, do, you wouldn't get 120 FPS. Yes. And I tweeted it, one of the Safari engineers, saying, why is this? And I think they were saying, oh, well, we're worried about legacy code that assumes 60 frames a second. And I was like, come on. Probably not a big deal. Probably not a big deal. Who does that? And they sent me back one of my canvas examples from four years ago, admittedly. But still. But still. Shame on you. Shame on me. So that's something. So CSS animations don't have this issue? No, they don't. Because you are CSS, by the very nature of CSS, as declarative. So either you use CSS transitions, where you say, go from A to B in one second. It doesn't care about frame rate. You don't get visibility into every frame, so. Same with CSS animations. Same with Web Animations API, which Safari is working on. It's now behind the flags. You can start using it, which is really cool. Oh, I did not know that. Yeah, if you use these technologies, the animations will run at 120 frames per second. And that's really cool. So what's the answer here for request animation frame? What can we do? How can we get that to? It's going to have to be opt-in. It's my fault. It's going to have to be opt-in. But then even that demo I did, it was some snow. Snow fell. And so on 120 hertz, snow falls twice as fast. It's just a blizzard. It's fine. We can gloss over that. Exactly. And then even if we solve that, assuming we have a wrap at 120 hertz now, we still have a problem. Because as you said, we have twice the frame rate. And that means half the budget. Less time to do it. And so with some quick math in my head, I will tell you if you were running at, you would have an 8 millisecond budget per frame. That is half of 16, which we currently have. Yes. But the problem is that the browser has to stay fixed. And I think right about now, it's safe to say it's between 4 and 6 milliseconds on a desktop machine. I mean, it might change. Your mileage may vary. But that means on 60 FPS, you still have way more than half left. Because let's say that the browser needs 6 milliseconds. You have 10 left. On 120 FPS, you have 2 left. Oh, that's not a lot of time. That is not a lot of time. And so there's, of course, there's work for the browser to do. Optimizations to only do work when it's really necessary to make the things that have to happen really fast. Things that the browser can optimize. But also, I think the ecosystem needs to change and needs to look into moving, writing things in a way that they yield often to the browser, that you can basically do. Here is my little chunks of work. And whenever you need to ship a frame in between, here's the point where you can do that. So request idle callback becomes even more important. Even more important. And the second tool that you have, and not very many people use, is web workers, where you can spin up an actual separate thread and do work in there. And you can block in there. You can do all kinds of work. The main thread won't care and will stay responsive. So something to prepare for in 2018? Definitely. I think there's an opportunity to, if we did have a go for another function name, I think there's an opportunity to rename requestAnimationFrame to something a little bit more meaningful. That's not the best name, is it? Like, yeah, so if it was like before render. I request an animation frame. Right.