Paul: Hi there, and welcome to PodRocket. I'm Paul. And today we're very lucky to have Jake Archibald on with us. How are you doing, Jake? Jake Archibald: I'm moderately okay. We spoke just before the episode that we are both feeling a little bit ill. So, if listeners can hear like any hard edit points, then we've both gone away to, I don't know, throw up or worse, but audio is relatively easy to edit, so people won't even realize that's happening. Paul: We're doing well enough to hopefully give our listeners a nice entertaining episode, informative one on animations and some of the new announcements that are coming out with the new Google Chrome Canary. So, Jake, you are a developer advocate. Is that what you would summarize your title as for Google Chrome? Jake Archibald: Yeah. Why not. So, every time Google I/O comes around, they send out a form to say like, "What would you like your job title to be for the videos and for the website?" And every time I put... So, I don't care too much about titles, so I always write something like, adult child who writes code. And every time they say no, and I settle on something like web developer, or they just end up putting developer advocate down. But yes, I think, officially, it's developer, programs engineer, or developer advocate or something like that. Paul: Got you. But you're still in with the code. You're still getting down and dirty. Jake Archibald: Yeah. I mean, developer relations seems very different at every company, but my day-to-day is building tools working on web standard stuff, feature design. But yeah, I do podcasts like this one, videos, articles. The of usual stuff people associate with the developer stuff. Paul: Right. And as we were talking about before, Jake. I mean, he has other talks, like on the JavaScript event loop. If you want to go check that out, he has one of those. So, well, transitions, Jake, there's something that some people use a lot of... Or animations, or none at all. Before we get into this, what's the difference between a transition and an animation in your mind? Is it the domain in which we're talking about, the type of DOM elements we're playing with or how do you draw that fine line? Jake Archibald: Well. Yeah, I was just editing a spec before, so I've got my spec hat already on. So, my answer to that question would be well it's how the spec defines the difference, which is defined by the CSS specs, where transitions is going from one value to another in CSS space. Whereas animations are a set of key frames and going between the different values. I think, in reality, outside of those spec definitions, there isn't really a difference. I suppose that idea of there's a before state and an after state and the transition is between the two, but the transition is just a form of animation. In fact, we're going to be talking about the page transition API, that is actually built on top of CSS animations, not CSS transitions. Jake Archibald: So, what normally happens when we make features is, we come up with an idea and we're going to build this thing, and then we've got a perfect name to call it. We're going to call it this. And then, someone puts a hand number and goes, "Oh, excuse me, there's already a feature called that." And we're like, "Oh no. Now we have to call it the second best name." And then, "Oh, no, there's already called that." "Oh, the third best name then. Okay." And we just keep going down the list until we find something that is unique enough to stand out on the platform. Paul: So, a transition, I'm like outlining in my head is, it has two states, before and after. And you can interpolate between these two words. Animations, there's more possibilities. You can have multiple states, there's key frames, and I guess it can lend itself to different use cases. And in the context of page transitions, I guess it makes sense. It's a transition because we're going from one state to another and was, we're delving into this, what is a page transition for people who have never implemented or have been too scared like myself to really dive into it? Jake Archibald: Yeah. So, I guess it's, you've got the before state and the after state, which, and most states are changed by messing around with the DOM in some way. Changing what's there on the page or in the case of a traditional web navigation, which gets called an MPA site to these days. It's the actual navigation of one page to another, represents the state change. And right now, what mostly happens or certainly the default is you're seeing the thing before, and then you're seeing the thing after, and that's it, done. Paul: The DOM repaints. It just goes here I am now, there I am later. Jake Archibald: Yeah. You've got a green square on the screen, and you take it away and you put it in its place. A purple circle or what the user sees is one switching to the other in the space of a frame. So, the idea behind a page transition is, what if it wasn't just changing? What if something else happened? And this is something you'll see a lot on, on native apps that you press a button, and it doesn't just switch to the next page. You get some visual transition from one to the other. It could be a cafe, a slide or some combination. Jake Archibald: And on one side, it's a nice, pretty thing to do, but there is a usability benefit in that. It shows the direction of travel in terms of the data flow. Is this notion layer a model that's filled the screen or have you switched columns of data? And so, even though it's a little delightful animation that goes along with it, also gives you a good hint at what maybe will happen when you press the back button, because it tells you the kind of switch that just happened. Paul: We're like cats, I guess, in the sense that we follow movement. Some of the examples that you gave in one of your talks with the mobile transitions. When the slide, for example, moves up, I mean, this is a classic mobile transition. You click back, right and something slides down and goes to the previous page or something. Your eyes follow that as it comes down and it can direct your attention. And I mean, this is just the tip of the iceberg, as you were saying, there's a lot of different ways that these page transitions can be useful for guiding the user in a particular series of premeditated thought. Jake Archibald: Yeah. So, a transition happens where the old thing slides out to the left and new thing slides in from the right, you have that notion that you're in a different column of data, that is a sibling to the previous piece of data you were looking at. Whereas, if the new thing slides over the top, then you have that feeling, "Well, that other thing is still there underneath." So, it's not just fancy animations, there's a usability side to it as well. Paul: So, why has this been a problem? And why has it been scary for page transitions? Because, I mean, there's so many libraries up for animating this and that, but we're talking about pages. Why is that hard? Jake Archibald: So, in terms of a traditional web navigation where you click a link and you go to a different page, there is no way of doing a transition to that because we have CSS, we have JavaScript, but when you navigate to a new page, the old JavaScript is gone and there's new JavaScript there. The old CSS has gone and there's new JavaScript there. They might be very similar to what was before, but it is a completely fresh context. Whereas, transitions need some intermediate states where the old stuff is still there alongside the new stuff, so you can animate them together in some way. Even across fade, you've got both things visible at the same time. When they're at 50%, you're seeing half of one thing, half of another. So, it's breaking the rules of a regular navigation with a single page app. Jake Archibald: You can have both things around at the same time that is code. You can write yourself, but you then have to deal with all of the other problems of having those two things there at the same time, like a screen reader is going to see both of them at once. Without a transition, you might have a button there and when it's clicked, the button goes away, because you've got the new thing. But with a transition that button's going to be there a bit longer. What happens if it gets clicked twice? All of these problems happen. If you're transitioning from a page that's scrolled, they're a thousand pixels down and you're going to another page that's not scrolled at all.At what point do you hand the scroll position back to the route element, if that's where scrolling is. Jake Archibald: And all of this stuff is somewhat solvable if you throw enough code at it, but there's the problem, you end up throwing 50K, 100K and more with each animation, you land. Even if the only reason you added a framework there is to do this stuff, then now you've just exploded the complexity of what you were building, just because you wanted a little slightly transition. So, that's what I wanted to stop, can we have these effects without bringing in all of that code? Paul: I mean, this sounds like a lot of complicated interaction between just the button example. When do I hand over the click event listener from this tree of nodes to the other tree of nodes? I mean, what if you have websites that are rendering crazy things? What if you have websites that, I mean, there's a limited capacity to the render horsepower of the DOM. And do you see us running into problems of naively stepping into this transition API and shooting oneself on the foot with that? Jake Archibald: So, the way this system is designed is, we give you an API and you say like, "I'm about to start a transition." And then, the API tells you, "Right, cool. I've captured everything as screenshots that you told me you want to animate separately," and then you do your DOM change. And then, you tell the API, "Right, I'm done." And now it goes in, it looks at new state and you create pseudo elements for everything that now is going to be independently animated and joins it together with the old stuff. So, the old stuff is now just a static screenshot. So, if you had a complex SVG animation going on, that is now frozen at the last frame that it was on, so that the JavaScript that was making that animation happen, or the CSS animation that was making that happen is gone. Jake Archibald: The new stuff can still run. We give you something that feels like a screenshot that you can animate, but it's a live screenshot to the DOM underneath. And now you can animate it just as you would, anything else with CSS, with the web animation API. So, if you chose to start animating box shadow and border radius, some of the things which do cause us quite a lot of pain overhead, and you're animating the border image and changing all of that stuff. You'll end up with a slow janky transition, but the default path will be the fast path, which is you're just sliding images around. And the browser is very good at moving textures around, that's the bread and butter of the GPU. Jake Archibald: So, the idea is not to take away developers' creativity, not to just make these transitions a very limited set, but still that for all the cases we already speak about as being that the faster and optimal paths, they will be faster and optimal in this API as well. Paul: Yeah. So, mostly something don't have to worry about because there's a lot of creative optimizations done about the sequence. And when JavaScript is loaded, when the screenshots are taken and how these components interact and... Jake Archibald: Yeah. Because we're using CSS animations, we're not doing anything super magic. So, the usual dev tools that you would use to measure animations and other performance stuff will work here as well. So, you don't have to do anything different. You'll see these pseudo elements appear in the elements panel. You'll see the paint, the compositing, all of that will appear in the timeline panel. So, you'll be able to identify if you're doing a border change and a blur at the same time, and it's causing you to drop frames. That will show up in all the same places and be an indication that, "Hey, maybe do something simpler." It's surprising what you can get away with. Jake Archibald: If your transitions are small and fast, which they probably should be. In some of my demos, I've had fairly complex things, making sure things are moving from the exact pixel to another place. And I ended up just taking a lot of that out and it created the transition looked pretty much as good because, as long as it, if it's fast and things are moving the right direction. These things can be pretty simple and really light in terms of paint and composite. Paul: It's the 80% rule. Is that what you're getting at a little bit with that? Jake Archibald: Yeah. I think so, but I wouldn't start like that. It's like throw everything at it, make the transition you really want to make and only start dropping stuff. If it turns out that it's this performance issue's there because you might find that there's none at all and you can have exactly what you wanted. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts, so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So, check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show. Paul: So, what do you think is the state of this API right now in terms of, if somebody's coming from the native space and the mobile space stepping into web, what are they going to find the same? What are they going to find different? What are they going to find one that's not in the other? Jake Archibald: So, we made this API for web developers, that was what I really wanted. I wanted this to be built on top of things, which already existed on the web as much as possible. And we just went and added a few extra things that didn't exist already. So, if people are coming from Android and the sort of transition stuff there, there will be familiar elements to it. You're dealing with sort of captured areas that have gone, and that are going to by default, animate from the old position to the new position, the old height to the new height. But if you want to customize it, you're going to be doing that, not with an Android API, not with an iOS API. You're going to be using CSS animations or the web animation API. Paul: And do you feel like the interactivity of this API, is that you can choose pre slated transitions between pages like there's a fade API or... Jake Archibald: Fade is the default. The default is for the old thing to change width and height to from its old state to its new state and for it to transition the position from its old state to its new state, while cross fading the previous and new content. But these are all CSS pseudo elements, so you can just target them with CSS and do whatever you want. We are not the first browser to ship page transitions in some form. It was first done in a nonstandard way in Internet Explorer 4 and that was back in 1997. Where you would drop this meta element on your page and you got to pick from a little menu of, I think about 22 or 23 different transitions. I think it was about five different transitions, but you know, each one was multiplied by from the right, from the top, from the bottom, from the left, and we even had our first proposal API was actually a little bit similar to that. Jake Archibald: And I wasn't happy with it because I think we should be able to customize these things, but like a good little boy, I wrote the article about it and I wasn't critical about it externally, because I wanted the developer reaction to be real. I didn't want to be accused internally of encouraging developers to parrot my view. And it was great, I put out this article and said, "Hey, you can choose from this set of presets." And people were like, "Well, that's rubbish." And I'm like, "Yes, I agree." And I was able to take this as massive evidence internally, and so now we've the default preset is that cross fade. But from there you can do well, whatever you can do in CSS. Jake Archibald: So, if you want the page to spin 360 while it's cross fading, that's awful, but you can do it. Why not? If you want it to flip over like a card in 3D, we've got 3D transforms, you can do it. I fully expect people are going to create some awful, awful transitions with this. Just like people can create awful, awful website designs, but that's what you get with full freedom. And I guess it's down to me and people with more design skill to provide guidance for what the right thing to do is here or encourage people to make more subtle transitions and respect users wishes. If they prefer reduced motion through the operating system suggestion and either turn transitions off or make them more subtle. Jake Archibald: I compared this a little bit to when Photoshop first shipped and it had that you could put a lens flare with one click on any photo. And what I did was I was like, "Well, I'm putting five of those on every photo because it looks totally cool." And yeah, it took me a while to realize like, "Oh no, this is actually gross. This is an effect that I would use only in very particular circumstances." We'll go through the same thing with the transitions API, but yes, in my talks, I will be encouraging subtle transitions rather than things that are going to make people feel nauseous. Paul: Spinning and fading. Come on, Jake, I mean, that's your classic newspaper animation. The newspaper comes in, it's like... Jake Archibald: Exactly. Even when I was saying that I was actually picturing the old Batman series, which I used to watch when I was a kid. When, when it would go, [inaudible 00:20:37] and the Batman logo was zooming and out. You can do that. You can actually do that, apart from the sound. Well, no, because the transition API doesn't do the sound stuff, but you could create an audio context and do this stuff anyway. In fact someone should do it. I want someone to go and make the 1930s Batman transition API. I don't think it's the '30s, it's much later than that. Paul: Well, that sounds like a cool way to get tool in with this. I mean, honestly, because you're taking audio at an outside context and making interact with these pseudo elements as they change. Be a cool way to actually see what's going on. Jake Archibald: Okay. So, when we had the API in Chrome Canary, I said like, "Here's the kind of dev tools I think we need. I think we need some way of playing these animations in slow motion or being able to look at them frame by frame." Because especially these things are going to be fast. So, debugging it, you don't want to have to go in and manually make all your animations slow every time. And then, one of the engineers said, "Oh, we already have it. It's the animation panel in dev tools and we got it for free," because the animation panel is there for debugging CSS animations. Where CSS animations, it just works, there's a little button that says, please pause the next animation. You hit that. You click your link. Jake Archibald: The page transition happens but because all the animations are paused. Now it doesn't ever finish. You get a little entry in the animation dev tools. You click on that and you get a scrubber and you can scrub back and forward through the transition and see where everything's going and identify which elements are maybe in the wrong place or a slightly out of time. And when you're done, you hit the play button and lets the animation go, and the transition completes. Oh excellent. Yes. That's why we're using standard web stuff because we get all of this stuff for free. Paul: That must have been an exciting moment in planning. Jake Archibald: Yeah. It's odd because the reason we were wanting to build on the fundamentals is because we get to use existing dev tools because we get to use existing developer knowledge and things like animation libraries and all of that sort of stuff. But seeing actually happen unexpectedly was like, "Oh, yeah. I remember that's that was the whole idea behind this." Paul: Yeah. Standards and, I mean, it feels amazing when you plug something and it's like, "Oh, just works. I got for free." Jake Archibald: Absolutely. Paul: So, right now the transition API, would you say it's alpha, experimental, beta, what's the state? Jake Archibald: So, right now it is. I think what we class is an experiment in Chrome. We have a origin trial, so you can use this on a live site. If you go through the origin trial process, which I believe means that only a certain percent of your users will get it. It's there for running AB tests. It's how we help large companies in particular test the new stuff we're making. So, we can get good feedback on whether this is a good idea or a bad idea. If it has bugs or whatever, but for hobbyists or people just want to play around with this API. There is a flag you're going to Chrome Flags and there's a document transition or something there. I'll give you a link to the doc which has the full spelling of the flag you enable, which is just a little dropout down menu that you select and then the API will be there. But yeah, we want to get this correct rather than fast. Jake Archibald: It's a feature that's been close to my heart for many years. It's something I've wanted to be on the web. So, I think I'd have a very sad time if we ship this, and it turns out to be the wrong thing. So, it's there for developers to play around with now and that's what we want. We let people play around with the old API. They didn't like it and they were correct in that assessment. We've got the new one there. So, now is the time for in depth, honest feedback, because we're in a position now where we can make changes to this thing quickly. Jake Archibald: I'm still playing around with the API design. One of the first features to use nested pseudo elements. We're not the first, but I think we're the first to go three levels deep. And so there's a bunch of stuff we want to pick up around making pseudo elements, easier to deal with in general, but we don't really have much of a spec yet. So, it's not a stage where we'd expect other browsers to implement because we would need a spec before we do anything like that. Paul: So, what would you say this is? You mentioned this is close to your heart, this project. Is this one of the more exciting projects you would say you have embarked on in the past while? Jake Archibald: Well, mostly in my sort of standards career, I've mostly worked on low-level stuff. I believe in this thing called the extensible web manifesto, which was this doc from a good few years ago that a lot of assigned up to. The gist of it is that browser engineers and people who write specs are often worst placed to know the feature developers want exactly. So, we shouldn't ship APIs that do a small one off thing. There was a proposal for CSS spring easing that will do elastic easing, but it would do one particular kind of elastic easing. And, exactly, that kind of feature that I don't think we should be shipping because yes, it might meet the requirements of whatever partner encouraged a browser to propose that but if you wanted it slightly different, bad luck, Jake Archibald: So, I always believe, I want us to ship the tools for people to, not just do a spring easing, but a bounce easing. What's the lower level primitive here? So, I previously worked on things like service worker, bought signals, these kind of low level things. This is one of the first fairly high level APIs I've worked on and it makes sense as a high level API because if you're going from one document to another, we need that high level thing that sort of outlives both, that passing of the screenshots from one to the other. Jake Archibald: So, it's very different. It's very visual from the stuff I tend to work on. So, it's been a nice change of pace, but still again, that same mentality of, we don't want to just ship free presets or whatever or ship a certain animation where we got feedback from some large website that they want this kind of transition, and we gave them exactly that. And the rest of developers, "Sorry, you've got to have that one thing the other person wanted." So, being able to make this fully customizable is why I'm excited about this project. Paul: I mean, being fully customizable, people will come and hopefully develop their own higher level APIs for people... just making it truly pluggable, I can understand being completely in the interest. Jake Archibald: Yeah. Along the way when we think, "Oh, we need an ability to do this." Rather than just adding that little thing, we're trying to, again, dig down and can we actually enable? Can we get what we want? What we think we need? But also, a lot more and give developers the ability to come up with stuff that we never thought of, because the body of web developers out there is more creative than we are. Jake Archibald: So, an example of that was I mentioned that the default is cross fading, cross fading, two do elements on the web was impossible. It was just straight up impossible. And the reason for this is, well, how would you do a cross fade? If the elements have transparency and you want them to cross fade? The thing that feels like it makes sense is to fade one in while you're fading the other one out, but the math doesn't add up, because if you put like a 50% transparent thing on top of a 50% transparent thing, you end up with a 75% transparent thing. Whereas if you're cross fading from red to green, you wouldn't expect any transparency at any point across that animation because it's starts off solid, it ends up solid. Jake Archibald: So, we shipped a different blend mode. We've already got mixed blend mode there where you can do multiply, overlay screen that kind of thing. So, we shipped a new one called plus-lighter, which is a fairly well known compositing mode that does the maths differently. It's not like layering two things on top of each other. It gives you that ability to cross blend from one pixel to the other. So again, this is a feature that we needed for page transitions, but we didn't just ship it four-page transitions. It's now something you can do all over the DOM. Paul: Beautiful. And hopefully people will really take to this and will get some creative sprouts of now new ways for websites to run out of that. Jake Archibald: Oh, yeah. And I want to see people making silly transitions with this. Maybe not necessarily for live websites, but for just demos and stuff, like the Batman transition. I made a demo with the Star Wars wipe transition, when it sort of a faded gradient mask goes from one side to the other. Turns out that was actually relatively easy to do. I just found someone else had already done that transition, so I just took their code and applied it to the page transition API because it's yeah. Again, it's just a CSS animation and it all worked, and I don't think I would enjoy it if I ever saw it on a real website, but it's nice to see that it's possible. Paul: I guess the moral of the story here is if you're coming into page transitions, don't be scared. There's a lot familiarity, there's a lot of thought put into how plugability is handled. Jake Archibald: Yeah. I think what I would love to see people do is just, sky is the limit. Do some crazy stuff and then come back and look at it a couple of days later. And take an independent look of, would you really want that on the website? And sometimes it's just a matter of, well, what if instead of three seconds long that was 300 milliseconds long, that's usually the difference. Paul: And I mean personally, from my point of view, that's always the answer because my animations are always just too sluggish. That's why they look so bad. Jake Archibald: Me and a few friends, we worked on a little mind sweeper clone called prox. And I was on a long flight, and I had a few whiskey and cokes and I decided I was going to make a little animation at the start where the logo comes in some way. And I had this five-part animation where the letters come in, it's all changing random. And then, each letter pops into the final letter and there's little flashes and radial explosions and stuff. And I was so happy with this animation. And so, I got off the plane, met up with the other developers and they just went, "This is disgusting. We hate this." And the answer was just to remove half the steps, make it faster. And it was like, "Oh, it's actually good. It's still a bit silly and gross, but it's now not totally annoying." And so, I think page transition is going to be the same. Paul: So, Jake, before we wrap up because we are coming up on our window here. I'm going to throw in a point, which is that Jake has a good video on page transitions. He's standing with a clicker and there's beautiful slides and great bubbly sound effects and it keeps your attention. And it was a great video. I really recommend people go check that out. If you want to read further on the topic or watch, I guess further. Besides that, Jake, where else would you point people to start getting involved with this or with following you, if there's a Twitter you want to drop. Jake Archibald: I'm jaffathecake on Twitter, my DMS are open. So, always interested to hear from people. I'll give you links too,. We've got this developer guide that I wrote for the future, but also the GitHub repo where we're doing the future exploration and hopefully soon the standards work. So, if people want to get involved there and you can give feedback on GitHub if you want to do it in public. You can DM me, if you don't want it to be in public, but any demos you make, please show them to me because they look cool. And if they're gross, they make me laugh, so I like that as well. Paul: Well, Jake, thank you for your time. Thank you for letting people get tuned into what's going on with Chrome and these new page transitions and hopefully we'll get some goofy stuff just like you want. Jake Archibald: Yeah. Paul: Yes please. Awesome. Speaker 4: Thanks for listening to PodRocket. You can find us at PodRocketpod on Twitter and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.