Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave To Rupert and with me is Chis From Coyier.

[Laughter]

Dave: Hey, Chris.

Chris Coyier: I prefer 99.99% Coyier.

Dave: Oh, yeah.

Chris: I don't know why.

Dave: Raff -- Chris, the Raff, Coyier.

[Laughter]

Dave: And Dave, the Double Raff, Rupert are here to talk about something. Chris, what's on our agenda today?

Chris: Well, those were very obscure animation half-jokes. We're going to talk about animation, probably. I think we are because that seems to be the bread and butter of our two wonderful guests this week.

Believe it or not, the four of us, and the four of us being me and you, Dave, and we have Stephen Shaw. Hey, Stephen.

Stephen Shaw: Howdy.

Chris: And David Khourshid. Hey, David.

David Khourshid: Hey. How's it going?

Chris: Good. The Keyframers, these two gentlemen, it's kind of their side name. Their circus name, perhaps; their stage name.

[Laughter]

Chris: Together, they form the powers of animation. You two fellows have lives of your own, of course, but this Keyframers thing is like you two getting on Twitch live coding some stuff, right?

Stephen: It's like animation Voltron.

Chris: Yeah.

Stephen: We kind of form together and become bigger.

David: Right. [Laughter]

Stephen: Not necessarily more powerful. Just bigger. Just bigger, yeah.

David: It's possibly the best and worst way to describe what we do together.

[Laughter]

Chris: Well, I've been on the show before, and I've been a longtime fan of it since you started. I guess you're sort of kind of in like season two of it right now, right?

Stephen: Yeah, we started year two, season two, 2.0.0.

Chris: Nice.

David: Yeah….

Chris: The gist is, you find some animation and then look at it with the audience in real-time. I have no idea how much planning you all do, but it doesn't seem like very much.

David: Zero.

Chris: [Laughter]

David: Absolutely zero planning.

Stephen: None. It's actually a carefully cultivated image where we look like we haven't prepared.

Chris: [Laughter] Well, that's not to say that, like, oh, these guys don't prepare. It's that the point of it is to kind of think it through as you go because that thought process is so interesting.

David: Right.

Stephen: Yeah.

Chris: It's often a Dribbble shot. I think it almost always is, but I'm sure you're open-minded, right? Maybe they come from other sources sometimes or some other website.

Stephen: We've had -- yeah.

Chris: Maybe you don't even look under the hood but just kind of reverse engineer what seems to be happening.

David: Yeah, we've done a few that have been recreations of a specific animation on a website but about 95% of them are Dribbble shots or some existing kind of animation video.

Stephen: Yeah, and even the ones on the websites, we don't ever look at the source code. We don't even know how they do it. We do it our own way.

Chris: [Laughter] I think maybe David put it this way at some point. Sometimes you see that stuff on Dribbble and you're just like, "Whoa. That's some next-level stuff. That's not for me," in a way. Maybe the point of Keyframers, some of the spirit is to be like, "No, it is. You can do this. There are ways."

I guess the proof is in the pudding if you can recreate these things in sometimes an hour or thereabouts from absolute scratch and then kind of do it over and over and over. Maybe you're kind of leveling up the world's animation abilities, particularly on the Web.

David: That's kind of the goal.

Chris: Yeah, because, in Dribbble, who knows how many of them are actually created with Web technology? It doesn't seem like all of them.

David: Very few.

Chris: Or even most.

David: Very few.

Chris: Very few, you think?

David: Yeah.

Chris: Yeah?

Stephen: Well, yeah, because if you look on the tags and just the descriptions of each of the Dribbbles, they will often say what they're made in and the usual suspects are After Effects or sometimes you'll see some by Principle, things like that. Facebook Origami, that's another one, but After Effects seems to be the biggest, the favorite, oh, and InVision Studio. Yeah.

Chris: Oh, okay. That has some built-in animation tools too. That's cool. God, that makes me more interested in this Lottie thing. I think Airbnb is the shepherd of it now but promises to take these After Effects created animations and port them to the Web. Although, I think, once you do that, the control that you have….

Dave: Four hundred kilobytes?

Chris: Yeah, very large.

Dave: Yeah. Yeah.

Chris: The control you have over it is seeded in some way. It's certainly not as easy as a state machine based FLIP master, so maybe we should get into that a little bit.

[Laughter]

Chris: Dave, weren't you kind of curious, like the classics of the Keyframers?

Dave: Yeah.

David: The greatest hits.

Dave: Yeah, I'd love to know the greatest hits. Well, I was on Keyframers this week.

[Laughter]

Stephen: A little impromptu episode. Yeah.

Dave: For a good three minutes, but yeah.

[Laughter]

Dave: I guess, it's hard in an audio medium, but can you kind of recant or describe some of your greatest keyframings?

David: What are…?

Stephen: Yeah, there was one that went, like, [fast-moving sound effect] and then [fly and crash sound effects].

[Laughter]

Dave: (Indiscernible)

Stephen: Yeah.

David: Mm-hmm.

Dave: [Flying sound effects]

Stephen: Yep. Mm-hmm.

Dave: Yeah.

David: That's right.

Dave: Yeah, I remember. Then you were like, [shooting sound effects].

Stephen: No, that was the other one.

Dave: Oh, okay.

Stephen: Yeah.

David: Right, that was the staggering one. Yeah.

[Laughter]

Dave: But I've seen in episodes where, David, you're playing piano and you're animating keys over the piano. [Laughter] Is this a thing that happened once?

Stephen: [Laughter]

David: Yeah, we're trying to get more creative with our approaches, and so we did this keys and code. We did two of them so far where we just take requests from the audience and I play along. Shawn makes this visualization based on the audio wavelengths. I still don't know how he does it and he doesn't either, probably, but it just works. [Laughter]

Stephen: A lot of copy and paste. No, but, yeah, it's live coded audio visualization while David is actually playing and performing on piano. I've got the audio from that feeding into the browser and then we're using kind of the Web Audio API to hook that up to some CSS variables. Then we just go to town on making those animate.

Chris: Nice. All the way to the CSS level. I might picture, like, oh, how are you getting that data? It's probably Web Audio API, I guess, so that's already in JavaScript.

David: Yep.

Chris: You'd think the temptation would be to just stay in JavaScript.

Stephen: Yeah, it's just so much more flexible to have those as CSS variables. The last one we did, Keys+Code 2, we kind of built in a little animation picker in there, so we did five different animations during the course of it. You can select between all those different visualizers just by a simple data attribute change.

David: Mm-hmm.

Chris: That's visualization for the sake of it, in a way. You were doing a Winamp skins, in a way.

[Laughter]

Stephen: Basically. That's the goal.

Chris: Which is lovely and fun and is art, you know, as I understand it.

David: Nostalgic.

Chris: Yeah. Some of the stuff you do then also is how you swipe from one piece of content to another or how page loads in an interesting and attractive way.

Stephen: I'd say pretty much every one of our animations is centered around animating between state changes, so like toggling a menu, open and closed, or clicking into a modal or a details view.

David: Also, maybe it's just me, but that's the easiest way to think about it, right?

Chris: On and off, one, two, or three.

David: Yeah. Yeah. Right.

Dave: Then when you look at the Dribbble and then you kind of just try to identify the states. Is that kind of how you reverse engineer it?

David: Yeah.

Dave: Okay.

David: There's a whole lot of stop and pausing and being like, okay, so there are these states. Then we drag a little. Then it's like, okay, now we go to this state. Yeah.

Dave: This is all informed by your state machine stuff, which you've been on the ShopTalk before, but can you give a high-level state machine, state of state machine?

Chris: [Laughter]

David: Sure. Well, I'll even give it in a sort of abstract way. If you were to play with one of these programs that the designers on Dribbble actually use to make these animations, you will notice that the process goes, like, you start with one state of something and that's one screen. Then you design the second screen. Then you insert some dropdown--

Dave: Tween.

David: Yeah. Yeah, yeah, and you tween between each of the states. But the idea is, you're not specifically coding that tween because that's the confusing part. You're just coding, "I'm here and I want to go there. Do your magic and have it just magically go from first state to second state."

Chris: What is that? In the case of After Effects, that's the beauty of that software is that the magic just arrives?

David: Well, yeah. After Effects, in large part, it's vector-based, so you would have one vector object. You would drag it somewhere else. Maybe scale it. Maybe rotate it in a different keyframe. Then After Effects would know, okay, these values changed. Do a little bit of simple math and determine that we could smoothly animate it from its first position to its second position.

Chris: Okay. Okay, so we have some of that in CSS, right? A transition is happy to tween a color for you or tween a transform or opacity, but it's much more limited, right?

David: Right.

Chris: If we need the shape to change, it's not impossible on the Web, but now we're talking about adding additional software and things like that.

David: Right. We do use transitions a lot. I think that's most of what we use in animations.

Stephen: Yeah. Usually, we're figuring out the proper way to recreate that animation with transition and, like, what additional data we have to plug in, utilizing David's library FLIPing or recreating the FLIP technique to kind of make that happen with transition.

Chris: It's almost funny. It doesn't seem like you set out to use these libraries necessarily, but then you get started and you're like, "Well, here's another one where that would benefit in that case," right? Certainly, it's easier to just use the platform, right?

David: We did do that in the episode that you were on with us, actually, where we were just, okay, maybe we should make these fixed width. Maybe we don't want to have them fixed width, so how do we animate them? Then I was just like, hey, you know what? Let's use FLIPing.

Chris: Right. We've used the word "FLIP" a couple of times. I would think that a good--I don't know--people that follow animation pretty closely probably know what it is, but it is quite a mind-bending little piece of technology. If I attempted to explain it, I guess it would be the ideas that we're told over and over that some of the things that you can most cheaply animate and cheaply being a good word in this case. The browser has to do little work and, thus, it can do these really performantly, smoothly, and nicely.

There are only a handful of things. Just a couple, really. Like transform. If you need to move something around using the transform translate property, opacity for some reason is very cheap. I don't understand it necessarily, but it just is one, and a couple more. The idea is, let's say you need to move a ball across the screen, the most simple animation there is. The worst way you can do it is to animate its left value with position absolute because it'll just be janky and left isn't one of the small list of things that you can animate cheaply.

David: No.

Chris: I don't know if that's changing or not, but that's the world I grew up in is, like, don't animate left. That's bad.

David: Yeah, I highly doubt it, and it's because, with the browsers, you animate left, right, width, height. The browser basically thinks, okay, this might affect something else. Then it just goes berserk and says, "All right. All of the elements we need to check did you move because of this one rogue element is animating left?"

Chris: I see. It's like browser engine internals. It might affect other things, so I need to check and run all kinds of code.

David: Right. That's called triggering layout.

Chris: Okay.

Stephen: Mm-hmm. Yeah, that makes….

Chris: So, you don't do that. You use transform translate instead, which, just as a technology, means nothing else is going to be affected by this. It can't. That's the nature of the beast so it thus can do fancier things like use the GPU and whatever. I don't even know that you need to understand all that if you're just like, "I'm just going to use these properties to translate instead."

The thing is, sometimes it can be complicated to calculate the state of where you want it to go and where it's from. Isn't the idea of FLIP is that it reverses it? If you want to really smoothly animate from A to B, one way to do it is to make it state B by default and then use all these fancy properties to make it look like A to begin with but A has actually secretly already been transformed a bunch of fancy ways.

David: Right. Yeah.

Chris: Then when you want to move to B, it can undo all the stuff that it already did. It's like thinking of animations in reverse.

David: Mm-hmm. Yeah, just for the listeners, when we say "FLIP," we don't really mean a flipping, like on an X-axis or Y-axis, but it was a coined term. It was a term coined by Paul Lewis over at Google back in 2015, and it stands for First Last Invert Play where you have the first position. You measure the last position. Then you invert it, just like Chris was saying. You make it pretend that it's still in the first position. Then you play it so everything goes to zero, which means it finally ends up in the last position.

Chris: So funny.

David: Yeah.

Chris: It's like, do you want to do that by hand? Sure, you can, but you probably don't. You've got some library that makes that a lot easier, and it truly does. You almost don't have to think about it at all. It's pretty neat.

David: Right.

Chris: There are other libraries like I believe Vue occasionally used, like if you transition group or something in Vue. Don't you get that FLIPing concept for free from it as well?

David: Yeah. Yeah. Vue, you get it for free.

Chris: It's cool, but to have to think about it yourself isn't so great. I guess that's pretty common, that Keyframers thing. Like, well, we're just going to use this library because we're going to get all this performance for free from it.

[Banjo music]

Chris: This episode of ShopTalk Show was brought to you in part by 8Base. That's 8 like the number 8Base.com. Everything except a front-end in one GraphQL API endpoint, I love that.

I went on a Twitter thread rant the other day kind of about this because it was about front-end technology changes fairly rapidly, like new frameworks and new browser capabilities and new ways of working that make sense and shake out. I like that. I want to be able to take advantage of all the best ideas in front-end and evolve my front-end code bases over time, obviously.

When I do that, if I think of my front-end as this separate place and I just go get my data through APIs, it means that my data, my data modeling, my back-end is somewhere else. It gives that the freedom to evolve, change, and take advantage of the best practices of back-end. Separating those two things makes a lot of sense. It's a nice way to work. It gives freedom on both sides.

8Base is part of that world, which I just love. I was ranting about this before I even really looked into 8Base, which is great. 8Base is a back-end as a service. It combines the approachability of Firebase like the Sass sophistication of Force.com with loads of integration. On 8Base, any developer can launch production-ready apps. That means from MVPs, just like I need to slap something together; try something out; model something. All the way up to enterprise, so it's just for anything. It's where you put your data. You talk to that data through GraphQL.

They say 50% to 80% of the code developers write doesn't directly support app-specific use cases. It goes into non-unique systems and infrastructure management. 8Base abstracts that 80% into API first developer acceleration platform with powerful development tools and integrations. like they say, from MVP all the way up to enterprise-grade stuff. That's 8Base, 8Base.com.

[Banjo music]

Dave: Do you end up paying the cost upfront? You do all your measurements upfront. That could be kind of taxing if you had 20 different states or something like that. Is the idea that you just hide all the divs until that measuring is done? How does that aspect of FLIP work?

Stephen: Usually, all that indexing is able to happen in basically one frame or one kind of render cycle. You do all those calculations in one frame and get everything moved in that same frame or in the next frame. Then all of your animating is able to just happen smoothly because those calculations aren't having to rerun or anything like that. It's just focused on the actual movement.

Chris: What's a frame? Like basically 1/60th of a second or whatever? Pretty dang fast?

Stephen: Yeah. Yeah, and usually all of that calculation is able to happen that quickly or at least your animation is going to be queued until you have all that data available. You're not going to have any jank during the actual animation because of that, because it's all done ahead of time, so the animation might be a couple frames delayed.

Dave: It's kind of like, don't run with scissors.

Stephen: [Laughter]

Dave: Don't do math while animating.

Stephen: Right. Right.

Dave: Is sort of the advice?

Stephen: Don't run with your measuring tape.

David: Yeah.

Stephen: Measure everything out the first time.

David: But also, if you're FLIPing a whole ton of elements at the same time then, yeah, that might go past one frame. Then you're going to have this effect where you see everything at the last state and then it animates back to the first state and you have this really jarring digital effect. But to that I say, don't FLIP too many elements because, number one, that's bad for performance. Number two, that's just not a really good visual. There's too much going on.

Dave: Like your sleight of hand gets ruined, kind of.

David: Yes.

Dave: Yeah.

Chris: Oh, interesting. What other things like that have you learned over time, I guess, kind of like animation best practices, in a way? Are there ones you look at where you're like, "Um, I don't even think we're going to put this on the show because it's too much"?

David: We've had our violations of principles plenty of times on this show.

[Laughter]

David: But, I mean, we're not animating height or width. We actually do come up with some clever techniques for just adhering to that animating transform and opacity only. For example, if you want to animate or pretend like you're animating the height or width of an element without changing its child content because a lot of people would think, "Oh, okay. We could just transform scale," instead what you could is transform a background element. That's what we do and that's the illusion that we create to make it look like the entire element is growing even though it's just a pseudo-element or something.

Chris: I see, because the size is changing and height and width is one of those not on the checklist of performant list.

David: No. Not at all.

Chris: Okay. I see.

Stephen: We also do a lot of sliding layers. If you have been a Web developer for a long time, this was kind of a background image technique that was used to get rounded borders and fancy edges of things. You'd have these repeating backgrounds and then the overlaying edges and all that kind of stuff. We do that same kind of thing with elements to reveal parts of elements. You kind of overlap the two layers, like the parent is moved over to one side and the child is moved over the opposite way so that only part of that child is visible. Then you can just use translate to animate those smoothly. That usually comes up a lot for us.

Chris: Sliding layers.

Stephen: Sliding layers.

Chris: What else? Do you have anything else in your mind about this, like what makes for good versus bad or too much versus too little? Is that kind of thing completely dependent on the project? I'm sure some of it is. Is there newbie mistakes, that kind of thing?

Stephen: I think a lot of it is knowing about the rules so you can know when it's okay to break them. We talked about the most performant properties being opacity and transform, for the most part, but there are certain things that you're just never going to be able to do with only those properties. By understanding that other animated properties are going to be more costly, you can know to limit the scope of them or utilize will change. What's the isolating CSS property?

David: Contain.

Stephen: Yeah, contain.

David: Contain layouts and stuff like that. That's basically a way. I think it's Chrome only. I could be wrong, but it's a way of saying this element, we are going to change its top left with whatever. We might change those layout properties of it, but I promise you it's not going to affect any other element.

Chris: Really? That's so funny. It's yet another. I feel like, over the years, we've made ourselves a little bucket of things that we seemingly weirdly need to tell the browser about where you'd think, like, "Aren't you a computer? Don't you know that stuff?"

Responsive images is the first one I always think of where you're like, "Can you tell us how big this image is going to be upfront so we can make decisions around it?" I feel like that twists some people on its head. It's like, "Why don't you just look and see how big it is? You're a computer. Can't you just know that fact?"

It's like, "Well, but I haven't downloaded it yet." I guess that makes some kind of sense, but will changes in that bucket, too, and perhaps this contain property, too, where you're kind of telling it what you plan to do so it can make smart decisions. You just have to because there are just too many other ways that your authorship could get involved and screw with it. You've got to make it some promises so it can make smart decisions on its side.

David: Mm-hmm. Funny enough, looking at the compatibility table, Firefox recently got support for it. Edge is coming out next with support for it. Safari, I don't really care about because I have an Android. Yeah, I would use it. I think I'd play around with it.

Chris: You're talking specifically about this contain property in this?

David: Yes. It's called CSS Containment. It's a candidate recommendation.

Chris: Okay.

David: With the WPC.

Chris: What are the possible values of it? Is layout one of them?

David: Well, it's layouts. There are paints. There is content. There is size. There's style, which I guess is the entire style of it.

Chris: Wow.

David: Basically, things that you say, this won't touch anything else. It won't affect anything else in the rest of the document's tree.

Dave: Man, I feel like I'm not smart enough to make these judgments sometimes. Do you just get a sense or a feel for when, like, "Oh, yeah. I'm not going to violate the layout"? You know?

Stephen: It kind of comes down to just understanding the way the browser handles that rendering and handles certain properties. There are some good kind of cheat sheets out there that show exactly which parts of the render cycle that that property affects, like width will affect layout and compositing and all of these other properties.

Understanding what that change is going to actually do to the browser, you can kind of reassure the browser, "No, no-no-no, it's cool. It's cool. I've got this under control. I know what's happening. You don't have to worry about that."

Chris: What are the implications of getting it wrong? Extra jank?

David: I don't know.

Chris: Yeah?

Stephen: Potentially, or just a weird side effect of what's actually contained.

Chris: That's interesting. It's almost like I want to leave it to libraries.

Dave: Yeah, it feels like driving a manual stick shift. It's like, "Sure, I can make my car go real fast," but for most people, that's a lot of action for understanding how that stuff works.

Chris: You can take off from the stoplight in third gear if you want to, but it's just not a super great idea.

Dave: On a hill. Yeah.

Chris: Yeah.

David: Not a good idea. Yeah.

Chris: Well, that's interesting. I have this moment, and I almost feel like the first time I have it, I'm going to blog it because it'll blow my mind. I've known about will change for years and never have I applied it in a situation where I felt like I could see, before I applied it, it didn't work as well; after I applied it, it worked well. This has never happened. [Laughter] Not to me, anyway.

David: Yeah.

Stephen: Yeah.

Chris: I'm not a Keyframer, so I don't animate.

Stephen: I've never seen a huge impact on it. I don't know what scenarios really, really benefit from it. But it's mostly about helping the browser make informed decisions about what to do with those elements.

David: Well, so with will change, especially with transform, you're basically saying, "Hey, just ahead of time, put this in its own compositing layer so that when we do animate it in either transform or opacity, that is ready to go," and the GPU could just go up and running. It's sort of like going to bed with all of your clothes and your shoes on and your car keys in your hand.

Chris: [Laughter]

David: Just so you could get up and get running at a moment's notice.

Stephen: It's like the browser dressing you while you're in bed to get you ready to go.

Chris: I actually like this. I think that's a great analogy that you're just ready to go.

David: Yes but, of course, that incurs a cost if you do will change to every single element. Then the browser is going to be like, "All right. I expect every single element to transform or change opacity at some point in its lifetime." That incurs a huge memory cost, which makes it slower.

Chris: Yeah. You could screw yourself, in a way. How about will change, star will change everything, or whatever? You've applied it globally. That's worse because….

Stephen: That's almost as bad as star position relative.

Chris: [Laughter]

David: Oh, my.

Chris: Ooh, that was an internal dig.

Stephen: [Laughter]

Chris: That's a personal--

David: I am triggered.

[Laughter]

David: You want to lay this out?

Dave: Uh-oh.

Stephen: This is just a common thing that we riff on, on the show. David is a big fan of making everything position relative.

David: It's Chris's fault. It is Chris's fault.

Stephen: The default position attribute is static. That has a lot of weird things about it that I think position relative is the smarter default, but nobody is used to that because everything is static. It makes sense, but I just like to dig at him on it.

Dave: I think override defaults is a generally accepted computer science principle, so always override defaults….

[Laughter]

Chris: Well, it's hard to think about it. Every time you've written position relative in your codebase, imagine not having to write it. It's gone now because everything already has it. That's easy to imagine. I bet if we ran that over the CodePen codebase, we'd probably remove 100, at least, lines of code, which is kind of cool. Yeah.

David: I actually did do it on the CSS-Tricks codebase just to, I guess, prove an internal point and win an argument with myself.

Chris: How many times have I written that line?

David: Oh, hundreds.

Chris: More than 100.

David: What I did was, I did that whole star position relative thing and I was like, what are the effects of everything being relative? There was just a tiny part of the CSS-Tricks thing where it was broken. I added a couple lines of CSS and I was like, okay, well, that fixes it.

Chris: Right, because that's the idea. Then you'd have to undo it in certain situations, but you're saying you'd have to undo it a lot less times than you have to redo it.

David: Exactly.

Chris: Yeah, okay.

David: Yeah.

Dave: I don't know. See. Position static is valuable because--

David: Oh, I love this argument. I know what you're going to say. [Laughter]

Dave: Because--

Chris: [Laughter]

Dave: Because -- hold on.

David: [Laughter]

Chris: I saw one just the other day, though.

[Laughter]

Chris: I think Andy Bell blogged about breakout buttons. Did you see that post? It's like you put a button in a card. Then you put a pseudo-element on the button that is like position absolute coverage of the entire card.

Well, where does that coverage stop? That coverage stops at the very next parent of it that happens to be position relative and so, depending on the nesting of that card, you might have to undo a couple of levels to make sure that the coverage stops at just the right place. Not a big deal. It's a one-off, so I get it. It's not the strongest argument in the world.

David: Position static, you do have to depend on making sure that no parent has opacity or transform or anything else that affects its….

Stephen: Stacking context.

David: Stacking context. There we go. That technique works until you decide, you know what? Let's do a little transform or a little opacity on it. Then, okay, now everything is ruined.

Stephen: Yeah. Once it gets kind of shuffled off to the GPU, any layer, it essentially becomes position relative or it becomes kind of that parent container--

Chris: Oh, yeah.

David: --the offset parent--

Chris: Right.

Stephen: --to anything below it, so you do have to be really careful with what properties are applied and so it does get very confusing if you're counting on that offset parent being something way up the line but you have some obscure property on one of the parents in between.

Chris: Oh, yeah. I see what you mean. This is a classic, right? Let's say you've positioned absolute something dependent on a parent like a couple of levels up. Then some middle parent all of a sudden gets a transform property on it. That absolutely positioned element all of a sudden changes context entirely of where it's absolutely positioned because that transform has introduced a new context layer or whatever. Is that what you're talking about?

David: Yeah.

Stephen: Yeah.

Chris: Yeah.

David: You have to keep all that in your head because there's no way to know it just from looking at the CSS and there's no way to know it just looking at the HTML either.

Stephen: David employs the nuclear option to just make sure that everything--

David: It is the nuclear option and it is my favorite unpopular opinion.

Chris: [Laughter]

David: It's like saying the Earth is a cube and defending it to death. I will just take this to my grave. I'm going to use position relative for everything.

Stephen: It may be a Stockholm Syndrome kind of thing, but I'm starting to enjoy it with the episodes.

[Laughter]

Chris: I'm not. I'm not abhorred by it, but it has yet to compel me.

David: It was your idea first.

Chris: Oh, yeah.

Dave: Okay, I'm going to go next-gen. Position absolute everything.

Chris: [Laughter] Yeah.

David: Mm-hmm. Mm-hmm.

Stephen: Why not?

David: Serious performance chains.

Dave: Then body min high 4000%.

Chris: Yeah.

[Laughter]

Dave: Just to keep scrolling back.

David: Yeah, that'll fit those weird curved monitors that everyone has.

Dave: Got it. I got it.

Chris: That's nothing, you know, that's helped the Web less than document flow. You know? Who needs it? Set height on everything.

[Banjo music]

Chris: This episode of ShopTalk Show is brought to you by Netlify. That's Netlify.com. It feels like everybody I know has got something on Netlify these days. It's just kind of taken over development, developer consciousness in this world. It's great because it's not for absolutely everything but it kind of almost is, especially if you open your mind and think of rearchitecting and thinking how websites could be built.

They're really double-downed on this idea of JAMstack, which I couldn't be more in support of. It's so great. I'm not even going to do the acronym for you because I bet you know it. If you don't, just Google JAMstack and it will take you to a page that explains the philosophy of what it is.

Light philosophy here, it's kind of about the static hosting. It's like what if we could prerender most of our site. Feel free to think static site generator if you want to, like all the speed benefits, security benefits, and the fact that I can have it on a CDN and take advantage of all of that stuff. Isn't that great? Netlify helps a ton with that and makes the developer tooling and integration around that super good but then takes it a step further and says, "Hey, we know you can't prerender everything. Why don't you prerender what you can and then hit APIs for the rest of the data and do it that way? Fine. Cool.

How are you going to hi those APIs? Well, you could hit them client-side or how about we help you with cloud functions, you know, the AWS Lambda stuff that's so powerful and inexpensive these days? It's a little finicky to get started with Lambda stuff, but it isn't on Netlify because you just put node functions in a functions folder and they just run. You don't even have to have an AWS account. Netlify helps you with all that. It's incredible how they've abstracted it away.

To me, it feels like, wow, I'm this front-end developer building sites in this very comfortable way that I know is really good for the Web and these really powerful, resilient sites. But still, when I need back-end like features, like I need to use a server or run some node code to do some stuff, talk to other services, hit my own APIs, process some code, who knows all what, that's available to me too, even stuff like auth, even stuff like form processing, git hooks. They have so much cool stuff in Netlify, I don't even know where to start and stop talking about them sometimes because there's so much to look at.

Don't be overwhelmed by it. It's very simple to get started as well. In fact, you can just drag a dang--

You know the other day I was on CodePen. I exported a pen to a zip file, unzipped the folder, grabbed the dist folder in there, dragged and dropped it on Netlify because they have this cool drag and drop file, and it deployed a site to a domain. The whole video is like 17 seconds, and I feel like I took my time. It's also super easy and fast to get started. Take some files and get a URL in 17 seconds, let's say. Thanks for the support, Netlify.

[Banjo music]

Chris: You get done with a Keyframer thing. Oh, here it is. It's a beautiful animation. You've learned a lot along the way. You've probably even learned something but, certainly, the people watching, there's an educational component to it. They all tend to be one-offs. Have you thought about the people of the world that need to create an animation and have it live within an environment of lots of animations or part of an animation system? What are your thoughts on that?

Stephen: Well, the code we write is so good that they can just copy it and drop it in whatever their setup, whatever their system.

David: He jokes about that, but people do that.

[Laughter]

Stephen: Yes. That is definitely something we talk about a little bit in the show. As we're making it we'll say, "In the interest of time or simplicity of trying to fit this all within an hour, hour and a half, we have to make certain judgment calls and compromises. Obviously, if you're putting this into an existing site, system, or framework, or whatever, you're probably going to have to move things around a little bit. We try to explain the logic of what we're doing so that it's a little bit easier to translate that logic o whatever system you are actually using.

David: Yeah, and the logic is the important part. Even though we might have some parts where we're like, all right, we're sort of strapped for time. We're just going to do this real quick and it looks ugly. The entire flow of our animation is based on this idea of, your animation exists in different states and we use data attributes to change that.

The idea is, if you want to put this in Vue, React, Angular, or wherever else, it's the exact same code. Instead of changing the data attribute with raw JavaScript, you're now changing it within the framework. That's the only difference.

Stephen: Yeah. You had some interesting tweets the other day, David, talking about the typical to-do app example and those kinds of things. You were talking about wanting to teach more from the high-level logic of what actually happens. Can you explain that a little bit more, a little bit better?

David: You're talking about my example?

Stephen: Yeah, in one of the threads of that you were talking about wanting to teach from the logic of it or the theory behind it.

David: Oh, oh, right. Yeah. A lot of the tutorials and things you see online, it's very much like, okay, here is how you do it within React, within Vue, or something like that.

Stephen: With some very obscure setup.

David: That's why what Stephen and I do on the Keyframers, we're using raw HTML, raw CSS, raw JavaScript because it's more important to understand the basic concepts and principles and how to really, what I call, model how we form the solution, the solution being how we actually animate these complex Dribbble designs in HTML, CSS, and JavaScript because we take those ideas of, okay, here is how this animation is supposed to work. We present it in a general way. Then we sprinkle a little bit of JavaScript on it and then it works. That, I find, is a lot more valuable than, "Here is a third-party library for doing this," or, "Here is how you would do it in React with whatever props or lifecycle methods you would use."

Stephen: Right. Most of these pieces will translate really well into any of those systems, but we're explaining why we're doing it this way with just kind of the basic toolkit so that, if you have your power tool, you can do it even faster or do it even easier.

Chris: Nothing is more compatible than just doing it in some HTML, right? If you want to then move it to JSX, fine. You might have to jigger some stuff around, but you're probably used to doing that kind of thing already. Whereas, if you would have written it in JSX to begin with, that's less friendly to move backward.

Dave: Hmm. I'm not sold. Framework buy-in is pretty cool, so having to have -- yeah, well, hey. To each their own, I suppose. To each their own.

Stephen: Fair enough.

Chris: There are snowflakes to begin with, but it doesn't mean they have to stay that way. You probably pick some tasteful timings and things. Like you said, a lot of the stuff you do is a result of something opening, closing, sliding, moving, or whatever.

David: Right.

Chris: You picked something tasteful to match what was already chosen, but it's not to say that that timing couldn't be changed to be more cohesive on some other project.

David: Mm-hmm.

Stephen: Yeah. If you stack enough snowflakes together, you get an avalanche, so it all will fit together one way or another.

Chris: That sounds about right. That sounds about right. Do you abstract that stuff out? Is that a nice way to build animations is to pull out the pieces that make them? You've pulled out the states already, so that's kind of an interesting part of it. Would you pull out the timing, pull out the easing? Yeah?

David: Yeah, so we make extensive use of CSS variables to do that. We'll have a duration variable, an easing variable, and probably some others for colors and related things.

The easing that we use and the durations that we use, we try to keep it simple. If you see a cubic Bezier, it looks like digits of pie, then there's nothing specific about that. They are just pulling that from where and being like, "Okay, that looks good."

Chris: Yeah.

David: We use cubic Bezier of 0.50.51 a lot just because it's a very symmetric smooth curve and it's also really easy to think about.

Chris: What are those values? We should put it in the show notes.

David: Yeah.

Chris: There's a particular cubic Bezier that you think is particularly nice?

David: Yeah. Yeah.

Dave: You said 0.50--

David: No, no, no, 0.47123, not 24; that's too much.

Stephen: It's a secret code.

David: Yes.

Stephen: Yes. [Laughter]

Dave: Okay. Okay.

David: No, I think it's 0.50.51. If you imagine all of the control points of that, like the 0.50 just means the middle of the bottom and 0.51 means the middle of the top. Draw a nice curve and you get some sort of sign wave looking thing or cosign.

Dave: Checkmark.

Stephen: It's kind of like the old TV "Sliders" the S in that logo.

Dave: Oh!

Stephen: Extremely obscure reference.

Dave: I love it.

Stephen: But those of you out there know that show.

Chris: I'm on cubic-bezier.com right now recreating it and I see what you mean. Yeah, it's like a tilt-y to the righty kind of S.

Stephen: Right.

Chris: I'll have to try that out. It's one of those -- I feel like totally terrible at stuff like this where I try to mess around with an easing and anything I do just looks kind of dumb and bad. I'm just like, you know what looks kind of good? Not having an easing at all, like the browser default one looks kind of fine. Then somebody else comes along and puts in a nice cubic Bezier. I'm like, oh, dang. That is slick, smooth. I wonder if it's almost like you know how if somebody else makes you a sandwich it's always better?

David: [Laughter]

Chris: If somebody else is--

Stephen: Is that like 90% of my commits in the CodePen database?

Chris: [Laughter]

David: (Indiscernible)

[Laughter]

Chris: That's delicious sandwich, Stephen.

David: There is some science to why this feels so good or, I guess, mathematics, as you would call it, is because we are starting from zero. You might look at these other easing and how the control points toward a floating in the middle. That means it's starting from some other value than zero, like some other velocity or something.

If we're starting from zero, that's a very natural motion. We're used to just seeing animations and relating them to natural motion. If it looks too unnatural, that makes us feel uneasy.

Stephen: Yeah. It's about the physics behind it. If something is going to start moving, it needs that kind of ease up time to actually get moving. It's very difficult to move a stopped object.

The same with the slowdown. You want it to kind of slowly go into place rather than immediately slamming on the brakes and being stopped, so kind of following the motion and trying to think about how that would act in kind of a natural way.

Chris: That sounds about right to me. Yeah, like it's the wind blowing a blade of grass. Of course, it moves in a kind of natural way. I remember this example. I was at somebody's house and they had an Apple TV and it had photos. Have you seen that default screensaver on it?

Dave: Yeah, Ken Burns, kind of.

Chris: Sure, or in this case it as a bunch of them kind of Parallaxed out sliding by. You just watched them move by. Then there was some kind of Microsoft TV thing. This is classic, and I don't mean to fuel flames between these large companies for this trite of a reason, but this is just the way it was.

Dave: I'm writing a response blog post right now.

Chris: The way it was, there was a Microsoft TV and it had the same kind of screensaver on it with photos sliding by, which is just a weird irony of choices of TV computer products. You could just tell that the Microsoft one, they didn't put any kind of smoothness into the motion at all. It felt linear. Linear is an easing choice you can make. Isn't it transition timing linear?

David: It's like making no choice at all.

Chris: Yeah. There's no acceleration or deceleration. It just moves at a very steady speed. It actually is kind of useful sometimes, isn't it? I don't have a ready to go example, but I have definitely been in situations where I've chosen linear on purpose.

David: Like opacity, right?

Chris: Yeah. Okay.

Stephen: Yeah. Typically, opacity you'll want to be a little more linear. Otherwise, it fades out a little too quickly.

David: Any infinite duration animation because, obviously.

Chris: Oh, sure.

[Laughter]

Chris: Yeah.

Dave: Oh, yeah. If it has to spin around in a circle or else you--

Chris: I guess the obvious ending to that story is the pictures that were sliding by with this kind of linear motion, they just felt very stiff and no nice compared to the one that clearly had some more fluid stuff going on. It wasn't just their left to right speed. There was some other stuff going on, obviously, that made it feel a little unnatural.

Stephen: Yeah. The great thing about easing is it really brings things to life. I'm sure you all have run across the principles of animation or whatever it is, the Disney--

David: Yeah, the 12 principles.

Stephen: Right.

Dave: Yeah, like squash and stretch.

Stephen: Right.

Dave: Anticipation.

Stephen: All of those things, it's about the easing and the realism of it. You give this communication of the motion and the weight of the object, and all of this just through the way it's moving.

David: Yeah. I wish CSS had a weights property, like a mass property. That'd be cool.

Stephen: Like a….

David: You know, we have height, width, depth. We just have these 3D properties. Anyway, I'm just -- [Laughter]

Chris: What would you do with weight in CSS?

Stephen: Well, eventually, getting into augmented reality and virtual reality, something like the A-Frame API would be super cool to have that actual physical model of the objects in there that you could manipulate with CSS.

David: Yeah.

Stephen: That'd be pretty cool. Another five, ten years, we're all wearing Apple Glasses and tossing 3D objects around. No? Nobody?

Dave: Uh-uh. One day.

[Laughter]

Dave: I use--

Stephen: You're on your own.

Dave: I've been in game development, and I've definitely pondered this a little bit. What if there were physics and Web stuff? I don't know what it would change. You click a button and it falls faster than the button made of a feather or something.

Stephen: Yeah.

Dave: They would land at the same time. [Laughter] I guess, I don't know the advantages now, but it is something I think about. They could react different, like, hey, this is a metal button so, when you click it, it's kind of dense. Then this is -- I don't know.

David: Feather button.

Dave: A jelly button. When you click it, it wobbles a bunch. For some reason, we have these two materials inside of our design system.

David: [Laughter]

Dave: It'd be curious. It would be neat to see ways to program. I guess Houdini would maybe allow this. I don't know what you'd do with it but it'd be interesting.

Stephen: There's a good portion of the future of the Web that will be AR or VR enabled. That is going to become increasingly important for Web developers to learn. There is always going to be the 2D kind of side of things, just as we have books and movies or video games, but augmented reality, I think, is going to be just a big gamechanger for the Web as we know it, especially for e-commerce kind of sites and all these experiences that can easily be ported into augmented reality. It's something to keep on your radar as a Web developer. I think that's extremely important.

David: Yeah. They should have called it Toudini because it's only for 2D.

[Laughter]

Dave: Ohh.

Chris: That sounds about right. Believe it or not, everybody, all four of us were in the same room just but two days ago. Can you believe that? Now, all four of us are in totally different cities; all four of us, different cities.

David: Yes.

Stephen: Yeah.

Chris: Such as the nerd migration.

Stephen: Different states?

Dave: Hold on. Technically, well, I'm in the same city - technically. [Laughter]

Chris: Well, I know, but we're in four different cities.

Dave: We have split apart. We were together for one point in time.

Chris: Which is fascinating. We were there for the Artifact Conference, which was cool. I spoke at it. Dave did as well. Part of my point was all this, well, there's so much crap a front-end developer has to do. It's more and more all the time because the browsers are more capable or just choosing to offload work in that direction for various reasons. We don't have time to get all into it here, but I didn't even mention animation once. It wasn't anything that I did other than the idea that a front-end responsibility is to pull off a design that you've been given, in a way. That was just like, of course, you have to do that. You have to do that and you have to do all this new stuff.

Is animation? It seems to be new and changing. Whose job is it? Do you think of it as a designer responsibility, a front-end design responsibility, or is it its own unique job? Is that stuff kind of yet to shake out?

David: Yeah, because there is no Web animator role, except at very few companies, maybe agencies, so it's still left to be determined.

Stephen: Yeah. I came from an agency job right before moving to CodePen. It was very much a collaboration because the developer has to inform, okay, what's realistic with the Web when we're considering the weight of the page, the devices that this is going to be on, all those kinds of things, whereas the designer has more of a grasp on the feel of the site and what's trying to be communicated.

There is kind of the balance between technical and spectacle, trying to meet in the middle somewhere with that. But the actual execution of it is going to fall on the developer side unless you're using something like Lottie where that can at least be offloaded a little bit on the designer or typical animator.

Chris: Or like Webflow. They're kind of big into the idea of, "Just use our tool. We have all these animations built in," or at least it's easier to use. I guess that's up for you to decide, but visual controls of the keyframes and that kind of thing.

Well, Dave, what do you think?

Dave: Yeah, I feel like we could keep talking about animation because it's so fun, but I think we will have to stop our animation….

Chris: Animation … paused.

Stephen: Can't we just pause it and resume later on?

Dave: Pause.

[Laughter]

David: Animation play state paused.

Dave: Yeah, but this is fun. Yeah, so I guess we'll do the standard closure. David, Stephen, for people who aren't following you and giving you money, how can they do that? We'll start with David.

David: How could they follow me?

Dave: Yeah.

David: Oh, yeah. I'm just David. I am @DavidKPiano absolutely everywhere on the Web: GitHub, Twitter, CodePen, LinkedIn, I guess, all those fun places.

Dave: Awesome. Excellent. You slay a mean piano, so we appreciate that when that happens. Stephen, how can people follow you and give you money?

Stephen: Most places I am @shshaw, on Twitter, CodePen, all that good stuff. Together, we're @Keyframers, twitter.com/keyframers or youtube.com/keyframers.

David: Keyframe.rs.

Stephen: Yes.

Chris: Nice!

Stephen: Our actual Web URL is keyframe.rs. We have a Patreon there that you can contribute to and support us on a monthly basis. I know Chris is doing that and has been an amazing supporter of us. Dave, I haven't seen you on there yet.

Dave: I can fix that. That's easy.

Stephen: Okay.

Dave: I'll fix that.

Stephen: You know, a little….

Dave: Yeah, you've got the twitches and got CodePen. It's a great place to dig around for your inspiration, so thank you. I'll join at the amigo level here, but I'm going to have to log in. Blah! Anyway, you lost me. Converse….

[Laughter]

Stephen: Oh, no!

Dave: All right. Anyway, thank you all so much for coming on. I see you all's animations and I'm definitely like, "I'll never pull that off," but I don't know. I'm inspired to even try.

Stephen: You can do it, Dave.

Dave: I'm inspired to try. I just need to FLIP it and state machine it, so that's easy. I'll do that. Thank you and thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, do you have anything else you'd like to say?

Chris: Hmm. ShopTalkShow.com.