854: Animating the Web With Matt Perry: Exploring motion.dev

Wes and Scott talk with Matt Perry, the creator of Motion (formerly Framer Motion). Matt discusses building intuitive tools, transitioning Motion to open source, and the future of web animation. Show Notes 00:00 Welcome to Syntax! 01:15 The Framer Motion story Motion 05:16 What’s the status of Framer Motion today? 09:08 What tech is Motion built on? 13:40 Is Motion entirely WAAPI? 16:06 Why hasn’t the Web Animation API gained more traction? 17:46 Does Matt design his demos? 19:25 Performance and testing 25:34 Brought to you by Sentry.io 28:10 Have other animation libraries influenced Motion? Svelte GSAP Anime.js 31:49 Micro-Optimizations in JS 36:02 How do you test frame rates? 38:03 Graphics programming and shaders Maxime Heckel Maxime’s blog 39:58 What is the future of Motion? 41:42 What’s the difference between layout animations and the Vue Transition API? 46:35 Sick Picks & Shameless Plugs Sick Picks Matt: Grime music P Money Ghetts Shameless Plugs Matt: Motion.dev Sponsor Motion Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax on This Supper Club. We're talking to Matt Perry. Matt's one of the brightest minds in modern web animation today. After making Framer Motion and Motion 1, Matt has created some of the most, I'd say, most painless animation tools to exist in modern UI development. I've used a ton of these things, and let me tell you, man, Motion has always had some of the coolest quality of life features of any animation library. So, welcome to the show, Matt.

• 0:31Speaker 01

  Oh, my pleasure. Thanks for having me on, Scott and Wes. It's a pleasure to be here.

• 0:36Scott Tolinski?

  Yeah, absolutely. I've been using your tools for a long time. I've done full tutorial courses on them, and I feel like I've done a lot of animation stuff. And I just want to say, thank you for thinking about the API and just the slimness of it all. Because, do you remember before Framer Motion came along? Was it React Motion? Was that the big one?

• 1:00Speaker 01

  Yeah, yeah. The big React animation API.

• 1:04Scott Tolinski?

  Yeah, and they all just felt difficult. I don't know if it felt the same to you, but I'd look at these animation libraries and say, why couldn't it be simple? Until, of course, I tried Framer Motion. So, do you want to give us some background on the Framer Motion story? When you started it, how you came about into this stuff in the first place?

• 1:22Speaker 01

  Yeah, sure. I mean, at this point, it's about 10 years since I started writing animation libraries. I guess it's at this point an addiction/habit.

• 1:32Scott Tolinski?

  Yeah.

• 1:32Speaker 01

  I started with one called, well, I called it Redshift to begin with, which is, looking back, quite ill-advised. And so, I ditched that pretty quickly and renamed it PopMotion. And it was through PopMotion, I think I wrote, yeah, I started writing Spring animations and stuff like this. And then, when I came to use it in production with a React website, it was quite... Like using an imperative API in a declarative environment, it's prone to, you know, things are prone to break and this site was breaking because of my library essentially, or at least the way that I took it up. And so I wrote Pop Motion Pose,

• 2:12Speaker 01

  which was more my attempt to like bring that declarative nature of React into animation libraries. And actually, I remember you talking about it on the show. I was super stoked to hear it. I just remembered the other day, I was in the, I was in the gym listening to Syntax and you started talking about Pop Motion Pose. You mentioned that it had a lot of plosives in the name. And I thought, I've never said that out loud. It really does have a lot of plosives.

• 2:36Scott Tolinski?

  We talked about, that was a shameless plug of mine, or a sick pick of mine in episode number 44. And then we also talked about it again in episode number 46. So that's early on.

• 2:46Wes Bos?

  2018. Man, that was a long time ago.

• 2:49Speaker 01

  Yeah, I'm feeling it now. I probably look a lot less fresh faced than I did back then. And yeah, so I wrote this library to make things in React essentially super simple. Like I wanted it to be, for anyone to be able to use it. And then at the same time, Framer were making a, like a prototyping tool that was based on React. And they needed an API that made it super simple to do animations because a lot of designers were using it. So they acquired Pop Motion. I came to Framer to work. And I made Framer Motion here, which was, it's been amazing. Yeah, it's been an amazing six years, to be honest.

• 3:29Scott Tolinski?

  Yeah. And for the people who don't know, Framer was kind of like a, when it first came out, there was a whole class of tools. It was like Figma, Adobe XD, Framer, and they were all kind of fighting for this same space. But Framer, the big distinction was always that you get to code sooner, right? That was like the big sell on Framer.

• 3:48Speaker 01

  Yeah, exactly. Like you could go in there, hack the pro. It was a prototype in design, so which was like kind of the unique spin. At the time, you couldn't make any animations in the GUI. You had to do it all by code, and that's why it needed to be as simple as possible, because even you'd be like some concepts like React. They're not obvious to a lot of people coming into coding for the first time, perhaps. Whereas I think of React as quite simple, and that's my bias and perception. But when you actually start user testing these APIs against people who aren't familiar with TypeScript and certain other environments, like it was quite eye opening.

• 4:23Speaker 01

  And it was nice as well, because I always felt like PopMotion had more of a, the original PopMotion had more of a reputation for, because I was really keen on it to be able to do anything. It had more of a reputation of being like harder to use in Greenstock. So I was dead set on the next API to be so simple that like anyone could use it. And now that Framer has turned into more of a site builder, the API usage is actually in Framer. It's like, hopefully you can do everything you need to do just via the interface. Like you can go in, add effects with the layout animations. You can basically draw two different components next to each other. And have them animate between each other, even though they're completely different DOM hierarchies.

• 5:05Speaker 01

  And that's been another fun part about working at Framer, like the demands that it places on the capability of the library is so much higher than it would have been if I was just writing this on my own.

• 5:16Scott Tolinski?

  So, okay, so what is the status of Framer Motion, PopMotion? What is the status of these today? Because I, when we first started chatting, you mentioned that there was some change happening.

• 5:29Speaker 01

  Yeah, I can announce, I guess, this is already out there, but Framer Motion is now independent. And I'm taking it to be like a community-based, open source library. It's just called Motion now. A lot of people ask for Framer Motion APIs in vanilla JavaScript or other view libraries. And with this change, we're bringing a lot of those Framer Motion APIs to every JavaScript user. There's still a couple of things left that I know, like a lot of people want like layout animations, which isn't there yet, but it's a good start. And all the hybrid engine, wappy powered goodness is there for anyone to use on any site now.

• 6:11Scott Tolinski?

  Man, layout animations, I gotta say, would be very stoked if that were to ever, ever happen. Because that was one of the coolest things where, Wes, I don't know how much you used these tools, but the layout animations was basically you were applying a wrapper around some stuff. And if the contents of that changed, the wrapper and everything would just kind of animate and shift and grow automatically. Really one of like the most magical features, I think, I had seen in an animation library when you guys dropped that. You also, at some point, came up with Motion1. My understanding is Motion1 is a web animations API library, is that correct?

• 6:51Speaker 01

  Yeah, and so that started really as like a side project because I didn't even know what... Like, I started wanting to write a book. In fact, this is how every single one of these projects has started. Pop Motion exists because I wanted to write a book about web animations. And instead I ended up writing a library. And it happened again. I wanted to write a book and I looked into Wappy. And there were certain like rough edges that I was coming up against. And I felt like whenever I see things like that, like a rough edge or something that I don't enjoy using, that to me, like I just see library. I'm like, great, well, how can I make a wrapper around this so I never have to worry about any of these details again? So with Motion1, the idea was really to, like, how much can I get out of the web animations API in the smallest file size possible?

• 7:36Speaker 01

  How can I get Spring animations? How can I get independent transform animations? How do we do that in like a tiny 3KB wrapper? But since then, because it was my side project, I think if any Motion1 users will attest, it hasn't really seen a lot of love over the past two years. Whereas Framer Motion has like, you know, sometimes the releases are like coming thick and fast, like, you know, multiple bug fixes a day. You know, sometimes it's quieter, but there might be like a barrage of new features. Motion1's not really seen any of that. But in the meantime, Framer Motion has taken a lot of the innovations in Motion1. So the Wappy animations and the hybrid engine, that now exists in Framer Motion. And it's gone further as well. It basically took the scroll animations...

• 8:21Speaker 01

  animations code and made it more performant and then laid in the ability to drop into scroll timeline API. Whether the situation allows, like if the browser supports it and the the animation is able to be hardware accelerated. And this approach, it's been taken a few places in frame or motion. So with this change, Motion1 is essentially deprecated, even though all of the APIs are still there. They're just certain props are named differently, but because it's been consumed into frame or motion. This is now, it's one library, motion, and it's for vanilla and React. So I understand that it's been a confusing ride, but now it's just motion, one library, JavaScript and React.

• 9:06Scott Tolinski?

  Okay, so motion.dev, okay.

• 9:08Wes Bos?

  For anyone who has never used frame or motion and is listening, I want to peel it back a little bit and understand what it's used for, as well as like the actual tech that's used under the hood. Because there's there's web animations API, there's there's CSS animations, there's keyframes, there's transitions. There's simply just updating CSS with JavaScript. So frame or motion is a set of utilities or motion is a set of utilities for adding animation to your web application, right? Like some of the most common one being like layout animations change from one to another, or if you want to pop something out. Is that right? Is that fair to say?

• 9:47Speaker 01

  Yeah, that's exactly it. And it was really there to shave off a lot of the pain points that you have with CSS. So for instance, animating something on mount, like when you add it to a page, it's actually like kind of, it's a kind of a pain. And I know that there's now the at starting style rule.

• 10:03Wes Bos?

  Yes.

• 10:04Speaker 01

  But obviously it's not like super well supported, even though I think it's a great step in the right direction. But I just wanted to make it as simple as possible. So you know, initial equals this, animate equals that, boom. Like you load the component, it's done. Exit animations, pain in React. So there's APIs for that. And it's just going through and addressing, synchronizing, you know, you can do a transition. You can do with CSS, you obviously can say, well, with this parent state, animate this child a certain way. But there's no real easy way to stagger those animations. And so that's another area where we. To the point where these are some of the first problems that I solved. And I kind of forget like how much it does or how much it smoothes away.

• 10:47Wes Bos?

  Yeah, architecting in CSS is a very hard thing to do where, oh yeah, you can add like a nice little hover effect. Or when you add a class or something, you can animate it. But you want to have a bit more control over the thing, especially when your data is in JavaScript land. It becomes a little bit tricky to do that. And sometimes it's much easier, especially when you're writing like a declarative language like React. It's much easier to use a library like this.

• 11:15Speaker 01

  Framer motion has like this gesture recognizer system inside of it. You know, it's nothing, I'm sure there's a lot more advanced, like multi-touch handlers or something. But it's more to get things like hover and press feeling more like they do on an app. And this is another thing that I sort of forget about where the hover gesture recognizer, which you think would just be a mouse over, mouse leave. But it does certain little things where it will filter out certain pointers. And, you know, so it won't do the whole poly field touch event. So when you touch, sometimes the hover state triggers if you're using CSS.

• 11:52Wes Bos?

  Yeah.

• 11:53Speaker 01

  So it's trying to, you know, smooth all those things. And again, I know you can do that in CSS, but like off the top of my head, I couldn't think of the API for it. It's like, you know, something like supports hover or contains, yeah, and then hover hover. And you just like, and you wrap certain code with that. And I just want to write hover that many times. Like, I just want to write, you know, on hover start, this is a real hover. While hover animate to this. And that's kind of how I work. And it's also a bit like fantasy CSS. So there's a prop called while in hover, sorry, while in view. And it's just while in view opacity one. And so then it attaches an intersection observer. Likewise, there's associated events.

• 12:33Speaker 01

  I want those events on an element, like when it pops into view, I want to add like, you know, listen, add an event listener in view. Like, I don't want to write a pulled intersection observer every time, but I want to do this sort of thing. So these are the smaller, like bitty things that it tries to take care for you.

• 12:52Wes Bos?

  That's good. And frame or motion uses, like, how is it actually applying those, those things? Is it just changing the CSS of the elements?

• 13:00Speaker 01

  Yeah, it's mostly JavaScripts. There's a few places where we change the like a style tag. For instance, the positioning of the on exit animations, we have like a pop layout prop, which will sort of like pop it out of the flow of the document. That's using a style tag, but on the whole, we're amending, we're running Wappy animations or we're amending the style attributes themselves directly.

• 13:24Wes Bos?

  One last one is Wappy is the web animations API, correct?

• 13:28Speaker 01

  Oh, yeah, sorry. Yeah, yeah. The web animations API, I always write this. I'm like, I'll write Wappy. And I'll think, okay, I'll change.

• 13:33Wes Bos?

  Don't worry. That's why we're here. We're trying to distill the things down. So everybody, everybody gets it. That's great. Sorry. Go ahead, Scott.

• 13:40Scott Tolinski?

  Back onto the web animations API. So you said the current version of Framer Motion or or just motion now uses Wappy under the hood and it's not just motion one? Or the future version of it will?

• 13:54Speaker 01

  No, it's a Framer Motion has also been using Wappy for maybe a couple of years, I guess.

• 14:01Scott Tolinski?

  Cool.

• 14:01Speaker 01

  I don't know. So what it will do is like detect a few things like can this animation be hardware accelerated? And if it can, then it becomes a candidate for for Wappy. So like capacity filter, click pass, transform, which we can accelerate these and definitely use Wappy because then it'll get promoted to a layer. And the whole animation will run off the main thread, which is, which is great. But there's a certain other like, there's certain features that Framer Motion supports or motion now that Wappy doesn't like, I think, repeat delay is one. So like if repeat delay set, then it'll de-opt onto the JavaScript animation engine. Yes, that's basically how it works today.

• 14:42Speaker 01

  And it's the same for the scroll animation stuff like we detect like, does the browser support scroll timeline? Okay, well, we can use that. Does it? Is it? Have we been provided a function? Or an animation? Because if we've been provided a function, we can still run out of scroll timeline. We just need to do it a different way. So it's all these different methods for just seamlessly switching between the most optimal engine at any given time.

• 15:08Wes Bos?

  Wow, man, so you have to implement something like scrolling the scroll timeline twice, because like the browser has the like scroll driven animations APIs now, but they're not supported everywhere. So you have to just like re-implement it also in like listening for a scroll event?

• 15:25Speaker 01

  Yeah.

• 15:26Wes Bos?

  Man, that's a lot of math.

• 15:28Speaker 01

  Well, I mean, you can always do a fallback, right? It's like stuck on screen or something, but a lot of people don't.

• 15:32Wes Bos?

  Yeah.

• 15:33Speaker 01

  Like if you're working for a client, that's I see that advice given a lot, but like try explaining that to your client. Like it's often, no, just use a scroll function and it will it will fall back in Dops where it has to. But we use the most efficient way where it can. And it's not finished yet, that one, like it does scroll timeline, but there's also a view timeline and the scroll function supports a lot of the same sort of like tracking elements within the viewport. And it's going to be great to release a new version where, you know, if if it's possible, we use the view timeline instead.

• 16:06Wes Bos?

  Man, so why don't you think web animations API has gotten more traction overall? Is just because everybody's using abstractions of it? I I I tend to teach it sometimes, but it feels like a lot of people don't know about it.

• 16:18Speaker 01

  I think off the bat, there's a lot of gotchas. So people are used to, I think, okay, but this is a bias, but it's my mental model there. If I say to something animate from zero to one, that I'll animate zero to one and I maybe I'll receive like a finished promise. And and after that promise, the the thing will that I animated will be at opacity one. Likewise, if I interrupt that animation and I say, okay, we're halfway through, but actually I want you to animate back to the, you know, to to where you were at, then it should take the position that it's at and animate back to zero or to its new destination. These are just like, from my perspective, these are obvious behaviors that should exist, but they don't.

• 17:02Speaker 01

  So you have to, so there's all these little gotchas that make it unpleasant to use out of the box. And, you know, it doesn't take much to to fix, to quote unquote, fix it, like the, you know, the current animate function, the mini animate function in motion. It's just 2.5K, but with that you get fully interruptible animations. You can stop and when you stop it actually stops, you know, whatever state it's in when you you've stopped it. Likewise, you you animate zero to one, the animation finishes, it is now at one. So there's there's certain things, I think just that is enough to bring it into the realm of like a like an easy to explain. Fun, even a fun API, like I don't think it just needed that little bit of salt and pepper, basically.

• 17:46Scott Tolinski?

  Man, I I gotta ask real quick, one thing that I've always admired about your work is the demos that you make. You know, a lot of animation libraries, I think they they really, you know, the the demos or the examples, that's like such a key point on like a little bit of a wow factor, but your demos have always been really just beautiful. Are you the designer of that? Are you? Is that? Is that your work?

• 18:10Speaker 01

  I don't want to say yes too eagerly because I don't know. And first of all, thank you because I actually was thinking the other day that I feel like my demos are a little Spartan. And like they can be a little very non representative of, and I know that there are demos out there like the App Store demo and the Apple Watch demo. Those ones like I'm like, oh, they're nice, but then I've done a time where it's just like plain colors and and very basic shapes that aren't necessarily representative of real UI. So that is something that I'm actively trying to, like, I'm hoping now that I I'm fully dedicated on on motion, that I have the time. So I've made like nice templates that right off the bat like look nice. So I'm looking forward to to start and making my demos of those.

• 18:53Speaker 01

  So yeah, I think on the whole, I've designed them because like the, you know, motion dot dev I designed took me a while. But I back in the way back in the day, I was like a print designer, that's how I started my career and then a web designer. And I only moved into coding a little later on, so hopefully I haven't forgotten everything that I used to know back then.

• 19:16Scott Tolinski?

  I mean, even the aesthetic of everything, whether or not they're simple demos, I think they illustrate really well the techniques in a way that like gives you confidence because they're so smooth and they look good. So it feels like a big part of of what you do is performance. Can you tell us a little bit about like what it takes to to one like test to get these libraries 60 FPS or whatever, but also like? How much time? How hard is that?

• 19:41Speaker 01

  So going forward as well, just because I've become independent, all the animations like motion still powers Framer. And it's going to and Framer are the project's first sponsor, which is amazing support as well. The nice thing about powering a design tool is that designers are obviously the most demanding people. And you've all, we've all like worked with designers who are like,

• 20:03Scott Tolinski?

  Yeah.

• 20:04Speaker 01

  Um, I want this and you say, well, you can't really have that because it's not gonna, it's not gonna perform too well. And they go out, well, sometimes they'll go, okay, yeah, that makes sense. I'll try and do it in the way that you suggested. Or, you know, not, but anyway, that, that conversation tends to be had. But you can't say to Framer, do this. And then Framer says, well, I can't really do that because that's not going to perform well because this and this. And sometimes we educate users like high blurs, get a little warning and like, don't do this because this is gonna be, you know, this is gonna perform poorly. But on the whole, there's an infinite number of ways to D up to a website. So in general, what I'm saying, the nice thing about having Framer is that people are going to do wild things.

• 20:48Speaker 01

  And you, like, that's an amazing test ground essentially to write against. So you get these projects now and then that are really high demand. And so you can use that, you can take that away. Uh, run it in your dev mode and you can just tinker with it to see. And the, the other thing is that the layout animation calculations, like they have a lot of more easily tested. Cause it's testing JavaScript, uh, sorry, browser performance is like quite difficult. It's quite difficult to get like, um, an isolated, consistent, reproducible device, I get, yeah, to, or environment. But there's certain things where like certain calculations that just don't need to be done.

• 21:28Speaker 01

  And so the layout animation tree has like debugging, uh, tools where it will report how, how many things are calculated, blah, blah.

• 21:36Scott Tolinski?

  Yeah.

• 21:37Speaker 01

  We can write tests where it's like, if you're given a tree like this, how many calculations did you run every frame? Because if it's more than this and something, one of the D optimization, uh, sorry, one of the, um, checks has, has failed. Pass where it shouldn't have. So just from the first principles, like do less like that. That's a big source of it. But when it comes to rendering, it does get more complicated. So it's more just iteration.

• 22:03Wes Bos?

  I'm curious how how you actually like actually test or how you reproduce a slow environment because I'm working on a new website right now that's using every new CSS property ever, you know, sticky blending. I have this little trail that animates throughout the website and it's just butter on my computer, but I know that it's not going to be butter on everyone's computer. So I was like, I gotta like, figure out how do I turn some of these things off when I do get to a device? And I could not figure out how to like, there's a Chrome Dev Tools has like a slowdown network request, but that's not like performance, right? So I finally ended up figuring out that I can turn off hardware acceleration

• 22:49Wes Bos?

  on Chrome and that gave me enough of a sluggish website where I could then try to track the frames per second when somebody scrolled, but I'm curious if you have any other tricks. I couldn't find any information out there.

• 23:02Speaker 01

  Yeah, it's really tough because like there's no good way of emulating the slow devices. Basically, you need to get like a mobile or some just really chunky, wherever you think that your lower end users are going to be. That's kind of where you need to the device that you need to be holding and using to test these things because like Chrome in the so next to the network throttling, you can also do CPU throttling, which is amazing. You can go up to 20x now, which is also good. The M4 laptops exist and you do need to like throttle it to that extent to get a nice reproduction, but things you can't emulate are things like GPU memory, GPU bandwidth, GPU.

• 23:44Speaker 01

  So a lot of the GPU made it. I didn't know that you could turn off hardware acceleration. So that's nice to know, but at the same time, a lot of the time, like I'll manually like, because we have pathways to, you know, put it on Wappy or not. So a lot of the times that's where I'll do that. So it's good to know.

• 24:00Wes Bos?

  Okay.

• 24:01Speaker 01

  The problem's more like.

• 24:04Speaker 01

  Have I made this layer too, like literally too big for the GPU to handle?

• 24:07Scott Tolinski?

  Yeah.

• 24:08Speaker 01

  Like, there's a good one, and it's especially easy to do in a design tool. Or like, is the GPU just slow? So it'll get harder accelerated, but that could have been worse. You know, there's situations where that's probably worse than just running it on the CPU. I don't know what situations they are, but I suspect they exist.

• 24:23Scott Tolinski?

  And yeah.

• 24:24Speaker 01

  So the messy, like the messiness of the device is kind of what you need. But having said that, we are talking about, I want to make like a performance API and put that into frame emotion and we can use that so that people can check the performance of that. Because we know how many animations are running, how many animations are running on Wappy, the framerate that we're putting out at the same time.

• 24:46Scott Tolinski?

  Yeah.

• 24:47Speaker 01

  So there's lots of metrics that we can collate. And then finally, I think there is an API proposal that is about memory pressure, GPU pressure, CPU pressure, and using it at device classes. And so by using some of those metrics in real time, like what I want to do essentially, I don't know if I'll get around to this, but one of the things I'd love to be able to do is dynamically switch off certain classes of animation. Like, for instance, like if we find that we're in a really constrained environment with the CPU, then we just disable everything that's not a Path transform clip path. Like, that'd be amazing, like, you know, I can only imagine the bug reports and someone coming in and saying,

• 25:27Speaker 01

  hey, on my nan's device, this animation isn't working exactly the way I designed it, but.

• 25:33Scott Tolinski?

  But it was nice. And if you want to see all of the errors in your application, you'll want to check out Sentry, at sentry.io/syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 25:59Wes Bos?

  Oh, and another little tip I have for anyone listening is Microsoft Edge has a new, they have this new thing that's like the 3D view, or you can like look at Z-index, and it's kind of cool. But if you open that up, there's a tab called Composited Layers, and it will show you the layers that the browser thinks that it should be painting, like when it puts something in its own layer. And then it will give you information on how often it's repainted, and the memory that it's using. And it's kind of not there just yet. It crashed on me quite a bit, but I was using it to try to debug how frequently something was painting.

• 26:40Speaker 01

  Is that new versus the Chrome DevTools Layers tab? Because that would be interesting, because they've said that they're deprecating that because it's so buggy. So it might be that we're at the other end of that lifecycle. It's not buggy because it's new, but buggy because it's old and loved, which is a shame because I use that a lot as well, yeah.

• 26:59Wes Bos?

  I use the layers too, yeah. Let me figure this out right, real quick while we have it.

• 27:05Scott Tolinski?

  Yeah, Layers Panel's always been one of the cooler ones. I used to use it a lot to figure out why the heck my page was getting pushed beyond 100% width or something, you know? Or just like just seeing what's off Canvas, or if you're placing things off Canvas, as we used to have to do a lot, like where those things were ending up.

• 27:22Wes Bos?

  It's not the Layers tab in Chrome. It's its own

• 27:26Scott Tolinski?

  Okay.

• 27:26Wes Bos?

  thing. I found out about it from one of the devs who works on the Microsoft Edge Dev Tools. Everyone always gives me a hard time for using Microsoft Edge. They're like, "Oh, whatever." I'm like, "Listen up. They're working"

• 27:38Scott Tolinski?

  Edge has their own Dev Tools?

• 27:40Wes Bos?

  "Super hard on the Dev Tools." They don't have their own Dev Tools, but they've extended, they've added Selector Performance, they've added these Composite Layers, they've added quite a bit for CSS performance, which I think is interesting.

• 27:54Scott Tolinski?

  Ah, I didn't know that. Thanks for the tip, Wes.

• 27:57Wes Bos?

  Yeah, yeah.

• 27:58Scott Tolinski?

  I don't even have Edge downloaded.

• 28:00Speaker 01

  Yeah, this might be the thing that's

• 28:02Wes Bos?

  Oh, yeah.

• 28:04Scott Tolinski?

  Yeah, Wes, look at you. "Microsoft, I'll hire this man." No, don't, please don't. Yeah. Have you taken, I know, I mean, you obviously do so much work with animations, building so many libraries. How many like other animation libraries are you checking out? Are you the type that's like getting into seeing how other people are doing it?

• 28:24Speaker 01

  Yeah, yeah, I'd, I'd take it quite seriously, I guess. Like I, I've dived into like Greenstock and I'm always interested, oh, how are they doing that? Why is this faster there than it is in my thing? And not like, you know, you uncover certain things that are kind of surprising and a lot of people don't need to care about a lot of the time, like coercing a number to a string, actually kind of expensive. So, you know, the number of times you can cut down on that, you're going to get a quicker per frame, per frame performance. So this, there's loads of tricks you can learn like this and likewise, it's interesting because you can, you also know in advance, like when something's going to be slower in another library, you'll look at something, you'll go, I bet that's slower in, in theirs and you test it and it is.

• 29:04Speaker 01

  And likewise, you'll see something they did and you're like, I bet, I bet that's where they got me on, on that thing. And Anime JS is another JavaScript animation library. And they're launching in January, I think, the new V4, which is sponsors only at the moment. Which I haven't, I just haven't got around to checking it out, but I really want to. Because they're doing cool things with, I say they, it's he, there's literally one person doing it. And I, I always used to appreciate the compliment of being referred to as a team.

• 29:32Scott Tolinski?

  Yeah, yeah.

• 29:32Speaker 01

  Fair part of these kind of like, it's just me. He's doing additive animations, which is kind of nice. I've never really, we do use them in Framer. So when you add multiple effects, like we could sort of blend them all, but under the hood, it's using like internal APIs. And it's just never, I've never found a nice way to do them, but anyway.

• 29:52Scott Tolinski?

  Yeah.

• 29:52Speaker 01

  Maybe this will be that nice way.

• 29:54Scott Tolinski?

  Huh, interesting. Did you ever take a look at like how like Svelte is doing animations? Have you ever dove into any of their frameworks? I know you're, you're pretty heavy in React land, right?

• 30:05Speaker 01

  Yeah, I'm probably too deep in the outland.

• 30:08Scott Tolinski?

  Yeah.

• 30:09Speaker 01

  The only thing that I've known, I follow Rich Harrison, like I've seen his, like it's sometimes he'll tweet about something that's quite interesting and it's something that he's done. Like, for instance, he synced, I think he's doing something around syncing animations that are on the main thread and using the JavaScript animation library to Wappy by using like polling. I think maybe they're polling the current time or something, which we have our own synchronization methods. But it's always interesting to see his approach because, yeah, I mean, something's felt is there's something that I haven't delved, delved too deeply into it. But I can tell there's something there because how much love you can tell because it's the people that love it. They, they, they express that love without having to be prompted.

• 30:50Speaker 01

  And you can see that the same communities have this like buzz around them and it's felt so obviously one of those. But, you know, now that motion's independent and I have time, you know, if it's something that's, you know, needed or wanted, then I might look into, you know, it's felt integrations. Maybe nothing, it might not be as extensive as, as, as deep as the motion component. But I think that is, I was looking at doing a view, like a little tutorial about doing, using the animate function with view. And I already liked, oh, well, there's a library, but there's a, and it's not like a full on motion component, but it is like, oh, this makes it nice to do like scoped animations within, within view. So maybe there's potential for, for those sorts of things.

• 31:36Scott Tolinski?

  Here's another one. I mean, you had mentioned that string to, was it string to number coercion was, was expensive?

• 31:43Speaker 01

  Yeah, the other way around. So don't you imagine if you do like just like zero plus pixel, you're kind of working the zero into the string.

• 31:50Scott Tolinski?

  I'm curious about like what other things are unexpectedly expensive, but also like what tools you're using to identify those like micro optimizations.

• 32:01Speaker 01

  Yeah, I try, I try to stay away from micro optimizations, more build up first principles, like this is just slow because obviously kind of things they like.

• 32:08Scott Tolinski?

  Can you explain first principles?

• 32:10Speaker 01

  Yeah, like, not really, because I use it. It's one of those smart words that I like to use. In my head, if you're unsure about something, there's like a set of sort of fundamental truths that you at least believe. And from there, you can rebuild, like using logical steps, like, like a correct outcome or decision, like it's a decision making tool for me. So what it actually means in science and maths, I can't tell you, but that's what it means to me. And so for me, like the, the fact that changing data types, like as far, as far as I know, from, from lower level languages, like it's usually like a big to do, like the CPU is getting very involved, you're having to write manual code.

• 32:52Speaker 01

  Well, if that's true, then it feels like in JavaScript, it should be the case that it's, that it's slow to, to stuff a number into a string, even though to us it's presented as just like an at or a template string, like which makes it super easy to do. And, and for most people and most things, it's fine. Like I do it all the time, but if I'm writing a critical path in the library, that's when I try and stay, or at least minimize, like, like here's, this is the moment we do the string concatenation is one thing and we do it all at once. So that's all.

• 33:20Wes Bos?

  Yeah, that, that kind of stuff bugs me a lot where people have like rules about that, that type of thing over like actually testing it. Because even with like CSS has, right, there's, there's a potential slowdown on your website. If you were to put a CSS has too high, like on, if you say like body has this thing, anytime the DOM is touched, then it has to recalculate and go through all of the elements and make, see if it matches one of those, right? And, and somebody posted that and now every time you post CSS has, everybody, that's super slow, gotta watch out for performance.

• 34:00Wes Bos?

  And it's really frustrating because it's like, well, here I am using Microsoft Edge Dev Tools and actually measuring it. And I always, I always like to tell people like, it's good to know about these things, but it's tools over rules, right? Measure it, measure it yourself and see if it's actually slow before you start fussing over that type of thing.

• 34:21Speaker 01

  No, 100%. And I spend a lot of time in the Performance Monitor, sorry, the Performance Tab. I only just discovered the Performance Monitor, very nice. But you can delve into slow things in your code. And it's only then, really, that I'll, that'll change things. Especially if it affects the readability. Like, I do, I feel like readability always first. I'm a little softer when it comes to. So here's another one that I don't do as a rule. Like, this is one that I actually never do. Because a lot of my code runs every frame. Like, I won't run a for each loop with an inline function. If I ever have to use for each, I'll preassign or prebind the function to something else.

• 35:02Speaker 01

  And that did bite me once, because I remember in the Pop Motion days, I had a nested for each. Which is easy, you know, it's easily done. Sometimes you need a nested loop. So now I tend to either do the prebound functions, or I'll write just a normal plain for loop.

• 35:16Wes Bos?

  Ah.

• 35:17Speaker 01

  But I did have this nested. I was like, why is everything so slow? And I narrowed it down to just this nested for. So you can imagine every iteration of this loop. New functions, new objects, but you're building a lot of new assignments. And that's, it's just slow. Because a lot of my code is per frame, I do care about them. But on the whole, don't care about them. Like, if it's a render, a render, and you're making a new function every render, then as long as that's not triggering like some further down component to re-render, then yeah, we should make a function. It's fine.

• 35:51Wes Bos?

  Yeah. It's a whole lot different. So literally one render versus, what, 100 times a second? You're doing it to get 100 frames a second? That's pretty crazy. Do you have a special monitor to make sure you get a specific frame rate? Or do you run it on, like, what? Because I've got, I think my MacBook Pro does 120, and my main monitor does 60, and then I also have like an older one that does, I didn't even know this, but it does 30, which I thought, wow, that's slower than I thought it would be.

• 36:22Speaker 01

  Yeah, because it's a consistent frame rate, everything probably looks really smooth.

• 36:26Wes Bos?

  Yeah, that's the thing, it's consistent, that's good.

• 36:29Speaker 01

  And that's another thing that I thought with this adaptive, if I could second, with the adaptive performance thing, like maybe you just start dropping every other frame. That might be interesting because like if you need that extra time rather than selectively stopping animations, what if you just did them at 30 frames a second? And that would feel a lot smoother than than running these things at 60 and dropping a bunch of frames and hitting like, you know, fluctuating frame rate. But no, to answer your actual question, I don't have a special one. I just use the MacBook because as you say, it's like 120 frames a second. I feel like Safari only very recently, or maybe still hasn't, run animations at 120, even on a MacBook screen.

• 37:10Wes Bos?

  Oh, really?

• 37:11Speaker 01

  Yeah, or maybe it could be request animation frame. But yeah, it's a longstanding issue of mine that Chrome, while getting that 120 frames a second, but Safari, at least until very recently, you weren't. And that can make it difficult because you want to put it to its test. Like, what's the worst situation this is going to run in Safari, like 120 frames a second? Right, well, like, you know, can I run it at that? Like, I don't know. Yeah, that was there. Yeah. One of those bugs that you opened like five years ago and you periodically poke your head in and it's like, oh, nothing.

• 37:46Wes Bos?

  Yeah, just totally ignore it.

• 37:49Scott Tolinski?

  I hate hitting those when you Google for something and you see a bug that's been open for like eight years. You're like, ah, not holding my breath. Yeah.

• 37:57Speaker 01

  Especially when it was you that opened it.

• 37:59Scott Tolinski?

  Yeah.

• 38:02Scott Tolinski?

  Yeah, yeah, no kidding. Have you, this is an off the wall question. Have you gotten into graphics programming at all, given your your background?

• 38:09Speaker 01

  No, I, I, I mean, I have, but not like deep. So like I've poked around with some shader stuff. But I can't remember what's next, last name. There's a guy called Maxime on Twitter.

• 38:24Scott Tolinski?

  Yes, what a, what a personal site that guy's got. Holy cow.

• 38:28Speaker 01

  And what a journey as well, because if you go, Maxime Heckel, H E C K E L, on Twitter, or X, or whatever people call it these days. He really only started learning, as far as I could tell, the shader stuff like a year or two ago.

• 38:46Scott Tolinski?

  Yeah.

• 38:46Speaker 01

  And I have so, so much respect for people who just pick something up like that. And then in a year or two, they're like the domain experts, like it's, uh, yeah, it's, it's super impressive. And the stuff he's doing with shaders and the way he can explain how he's doing these things and with these complex maths functions. And that as someone that's not from a mathematical background, someone whose wife, who is a mathematician, had to struggle through me, uh, learning matrix transforms out of a manga guide to matrix transforms and still struggling, literally a comic book couldn't teach me these things. He's great at like explaining those.

• 39:26Scott Tolinski?

  It's unbelievable. One of the top 10 blogs for me, the blog is incredible, the site is incredible. It definitely made me pick up graphics programming, not that I've done anything cool with it, but it's a whole different world. Cause what your, your code is running on every pixel, every frame. It's so bizarre to, uh, the way you have to think about it. You're thinking about every pixel at once. And this code is running on every pixel. Uh, what do I need to do for that specific pixel based on its position? Here's, uh, before we, you know, you know, move into like closing things or anything like that. What does the future of motion look like, given that now it's yours? You, you have what greenfield in front of you. Like what's the future? Where do you see this thing going?

• 40:10Speaker 01

  Yeah, it's kind of mad to think about, to be honest, cause I like, yeah, it's almost like the possibilities are not in a bad way, but like too endless. So it's not a question of what I'm doing next is what do I do first? And a lot of that's going to be driven by the community, like, you know, I'm open for sponsorship. So, um, now that I need, uh, need an income and, uh, I think a lot of it will be listening to sponsors and what they're after. So I always get requests for view, but I've never seen the libraries that I write for it like take off that much. But if the sponsors want it, do you know what I mean? Like I say, it's going to be a bit of a conversation, uh, there. And I want to take the principles of motion, like I want to take the principles of both frame of motion and motion one and, and bring them together essentially.

• 40:55Speaker 01

  So that means writing.

• 40:58Speaker 01

  Finding more ways to exploit browser APIs and get them to do more things for the smallest file size possible. So I already mentioned view timeline, but obviously there's view transitions. Can they, like, I think some people think that they're a different, like, they're an alternative to layout animations. The new docs explain why they're not really, if you go on the layout animations page, but they're complementary. And like, I write a view transition feature in Framer called page effects. And some of those effects you can only do with view transitions. So it's more of an and for me. And I'm thinking, can I make layout animations and view transition API work together? Like, is there something there? I don't know, but there could be.

• 41:42Wes Bos?

  Can we dive into that a sec? Like, what is the difference? So the view transition API, I did a little video on it where I had a CSS grid, and I took a video and I cut the video into 16 grids. And then I hit a button and it would randomly shuffle the order of the elements in the DOM, right? And when you click that button, it just immediately snaps to. But if you, if you start a view transition, shuffle them, then they will animate from one place to another. And you're right, it's somewhat limited in terms of what you have access to. But like, I'm curious to hear your thoughts on what the differences are.

• 42:22Speaker 01

  Yeah, I mean, for me, what it's really good at is like anything, like you've got to play to its strengths. So it's really good for full screen transitions. So crossfades, wipes, you can do all sorts of things of like masks. And the other nice thing, because it's like a unique architecture where it's taking actual snapshots of these elements and popping them out of the page. You can do things on a per matched element basis, where you can like crossfade things in a unique way. Or maybe you can, you can do something like, say you had an element that is static. In my head, I'm thinking of like, I don't know, like you've got a picture of a cartoon character and you're swapping the background. They're in a beach, they're in a shopping mall. You could like animate

• 43:05Speaker 01

  the scale of the person or the animal or whatever. And character you want up off the page wipe the background and then have that zoom back in. Those sorts of effects aren't super easy to do when you're animating the DOM itself. Is that in certain Z index issues as well because everything the nice thing about view transitions, it runs completely on top of the everything on your page. Um. So you don't get these um these Z index issues when you're like swapping elements around or whatever. But like you say, they they can't be interrupted, they're kind of full screen by default. It takes a lot of work to coerce them into being like micro interactions. And even then they're pretty bad basically for that use case.

• 43:47Speaker 01

  Um. Whereas layout animations, like they do all sorts of things that are completely tailored towards micro animations. They work on the DOM itself, which is in in the case of like a toggle switch, a good thing. They can be interrupted. Uh. And the other nice thing is you can use like mismatched um. Uh easing curves and durations and delays. Whereas if you had like a a nested two boxes in a view transition, they were nested and they both. They both had matching IDs in each transition and you tried to animate the parent over here. And the child would stay over here. This is a delay. Um. I've I've realized this is I could see myself and you can see me, but if you're just listening to this, I'm holding up my hands. To illustrate that there are boxes moving up a screen across the screen.

• 44:32Speaker 01

  But yeah, essentially the child will be left like stuck on screen where it was left behind by the parent. Whereas with um now animations, like uh the parent will move with the child, even though the child hasn't started animating yet. And then when its animation starts kicking in, it will move relatively to its parent. So there's a lot of things like that which we handle, but like I say, it's it's because it's an and not a nor. That I get excited. I'm like, oh, I wonder what you can do. Can you mix these things like? Um. Or even just as an API around view transitions to smooth out some of those edges enough. Yeah, that's what I'm thinking at the moment.

• 45:07Wes Bos?

  That's good. I I I'm excited that this is basically you're figuring out the hard parts. And when the APIs are usable, you'll use them and and when not, you won't use them and. I I like that kind of library where I just get to use it. And somebody much smarter than I has figured out what parts to use and where.

• 45:31Speaker 01

  Yeah, hopefully people have to run into this stuff once and that person's me. And she says, well, the bruises are on my face again. If you're listening to the audio, you can't see my face is covered in bruises from running headfirst into these problems. Yeah, I mean, that's kind of what, because I don't want to, I don't want to handle them again. So that's the sort of the driving force. Like whenever I run into these things, I don't want to do this again. And it's an interesting problem. How do I package the solution in a way that people want to use it? That's kind of the driving goal for me.

• 46:08Scott Tolinski?

  Yeah. Matt, this has been really cool, especially because I've been, I've been utilizing your work for so, so long. It's been great to hear all this stuff about it. And honestly, I'm really stoked for you to go out on your own here. And I can't wait to see, not, not just selfishly that I get to use your libraries again, because I didn't use React. So now like the investment in more JavaScript heavy APIs is a good thing for me. But let's get into the part of the show where we talk sick picks and shameless plugs. A sick pick is just something that you think is cool. You enjoy a shameless plug is your chance to just share with everybody what you want to plug.

• 46:47Speaker 01

  Cool. Okay. Well, my sick pick is Grime Music, which is a such a, well, it's, yeah, it's like, how would you describe it? It's like an offshoot from, I don't want to get into the history, but it's like an offshoot of like UK Garage, German based with MCs. And I feel like it never really took off in America. And I think it's a shame because it is, first of all, the best part of it happened when America was going for its mumble rap phase. And also there's just some like super inspirational people in the scene. And I want to specifically talk about P Money and Getts, G H E T T S. They're amazing.

• 47:28Speaker 01

  And they've been going at this thing for 20, 25 years and that work rate and longevity on something that not, hasn't always felt like. Super popular, but they know is amazing. I know it's amazing and I feel like those are the people, they're making hopefully music for people who appreciate that it's amazing and for themselves. And that's kind of like, I want to do something that people enjoy, I enjoy and that other people enjoy. And I just get, just keep, just keep going.

• 47:57Scott Tolinski?

  Yeah.

• 47:57Speaker 01

  And so, yeah.

• 47:58Scott Tolinski?

  He money gets.

• 48:00Speaker 01

  That, right. Incredible. There's plenty that I could, I could talk about, but they are for me, the, um, the two best.

• 48:07Scott Tolinski?

  I think Dizzy Rascal, uh, when Dizzy Rascal had that fix up, look sharp, that popped off here. And then Stormzy was kind of popping off. Is Stormzy considered grime?

• 48:19Speaker 01

  Uh, no, I, I think that he's, he's grime adjacent, like for sure.

• 48:23Scott Tolinski?

  Okay.

• 48:23Speaker 01

  I think he's a question. Yeah. Um, he's definitely had some, and he can be amazing on grime as well. Uh, he really can. But, but yeah, I'd, I'd stick with, uh, who's the first person? Dizzy Rascal. Yeah. Yeah. I mean, his first album is incredible. So that's also people to check out. And, uh, sorry, what was the other thing I was asked for? The, uh?

• 48:41Scott Tolinski?

  Oh, the Shameless Plaid. Just feel free to plug.

• 48:44Speaker 01

  Oh, well, this is an obvious one, isn't it? Like, yeah, I'm gonna go for motion.dev, um, specifically motion.dev forward slash sponsors. Um, but also just in general, please check out the, uh, the library. I've got some cool things coming up. I've got like a new courses page coming out, which is collaboration with, uh, people that you will recognize and hopefully a merch page soon after that.

• 49:04Scott Tolinski?

  Oh, sweet.

• 49:05Speaker 01

  Cause I need to make a living. So, uh, and I, I've been die testing certain pieces. I'm like, I basically, I'd almost sell anything until I'd wear it. So when you see a little motion logo just there, then you know that I found the, the thing that I'm gonna sell.

• 49:18Scott Tolinski?

  Nice. Yeah. Uh, everybody go do that because, you know, we've been really high on this lately. Uh, Sentry's been really big on this lately. Support the open source projects that you use. It's important. Um, support the open source projects that, uh, you know, make our lives so much easier and motion is certainly one of those. So definitely head to the sponsors page. Um, sponsor Matt if you can, you know, ask your company to, uh, the, the work has been amazing. So thank you, Matt.

• 49:46Speaker 01

  Oh, I really appreciate it. Thanks, Scott. And I appreciate, you know, the love over the years as well. Like I, it's, it's been noticed and I really, I do really appreciate it.

• 49:54Scott Tolinski?

  Yeah, of course. Wes, do you have anything else?

• 49:57Wes Bos?

  I think that's it. Thanks so much for coming on. We'll catch you later.

• 50:00Scott Tolinski?

  Thanks, man. Much love to me.

• 50:02Wes Bos?

  See you later.