Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast, episode 325 Legend List with Jay Meistrich.

Jamon Holmgren:

Hey everybody, I'm Jamon. She's Robin, he's Mazen, and we are React Native Radio. Today we have a really cool guest, someone I've wanted to have on the program for a long time, and it finally happened. Jay Meistrich, my good friend, of course, I'll have Jay introduce himself in a little bit here. But before we get into that topic, let's hear from our sponsor. Infinite Red. Infinite Red is a Premier React native consultancy located fully remote in the US and Canada. If you're looking for React native expertise for your next project, hit us up at Infinite Red slash React native. And don't forget to mention that you heard about us through the React Native Radio podcast. Alright, Jay, can you introduce yourself, talk a little bit about your tech background. You've done some really interesting stuff.

Jay Meistrich:

Yeah, yeah. So I'm Jay Meistrich. I think I started coding when I was 10 when my mom sent me to a computer camp over the summer, and then I got kind of hooked when I was in college. I joined a club at Carnegie Mellon called the Game Creation Society and ended up making five games there.

Mazen Chami:

Oh wow.

Jay Meistrich:

So I got really into the games industry. I interned at EA games, worked on a game called Boom Blocks on Nintendo Wii.

Robin Heinze:

Nice.

Jay Meistrich:

Nintendo Wii is a very restricted environment, so that was pretty intense. When I graduated, I went to Microsoft, I worked on Windows seven, and then I moved over to a research group where I worked on some computer vision and some high performance touch devices. I think performance was always really critical to everything I was doing. It was always top of my mind. And then when I left, I got into web development and the JavaScript world is very different in terms of how they think about performance. So that's been interesting.

Robin Heinze:

Performance, what is that?

Jay Meistrich:

Yeah, right. So then I started a company called Legend. Back then it was called Modu, and then I renamed it to Legend because that was a bad name.

Robin Heinze:

Modu

Jay Meistrich:

Moo M moo.do.

Robin Heinze:

I'm not going to contradict you on that.

Jay Meistrich:

Yeah, so the original idea was that it was like more than a to-do. It wasn't great. I kind of like it. Oh, thank you. So yeah, in doing that, I was making a web app and mobile app. It was all local first and it worked Offline performance is always really important. At one point I switched it over to React Native to get better performance, but it wasn't great. I had a lot of trouble with Flash List, sorry, flat list specifically. Then I made a virtualized list on web and one of my users ran the web app on his phone and said, Hey, your app is better than your native app. So then I migrated the whole app away from React Native back to web. So it's currently a React native app that just wraps a web view.

Jamon Holmgren:

Interesting.

Jay Meistrich:

Because of the list. So the flat list was the main problem.

Jamon Holmgren:

Yeah,

Jay Meistrich:

That was like five years ago.

Jamon Holmgren:

This is a little bit of a sneak peek into your personality and I've come to really appreciate it. We've been friends for a while now. I think we met, did we meet in Poland or was it Finland? I can't remember. It was Poland. Poland, yeah, in 2019 I think. Something like that. So six years now. So we've been friends for a long time. You've shown me some of the stuff you're working on. It seems like the common thread here is almost always someone's like, Hey, this thing sucks about the thing you made, and then you're like, I am not going to let that stand and you go disappear for months and come back with something that is just amazing. That is accurate. Have you always been this way or is that something that you've kind of acquired over time?

Jay Meistrich:

I don't know. Maybe it is.

Jamon Holmgren:

Yeah, I might've just given you a personal

Jay Meistrich:

Revelation about things in your life, and that's also basically where Legend State from is I had in Legend, I had a state system that I had built because I previously used Knockout js and I switched to React, but I really liked how Knockout worked. So I basically built Knockout in React, and then one of my friends said, oh, you should benchmark it, and I did and it was okay. And then I basically blacked out for a week, and then after a week I had something that was so much better and then I decided to open source it. And that's Legend State,

Jamon Holmgren:

Basically.

Robin Heinze:

Oh wow.

Jamon Holmgren:

Yeah, legend state's. Awesome. And we can definitely talk a little bit about that too, but also you and Eli White are good friends. And you had actually, from what I understand, you were the person that hired him at Microsoft.

Jay Meistrich:

Yeah, it was Microsoft. Yeah, we hired him as the intern on our team.

Jamon Holmgren:

Yeah.

Robin Heinze:

Oh my gosh, I can't, Eli White is an intern, is a trippy thought.

Jay Meistrich:

So what was he like?

Robin Heinze:

Yeah, as an intern, what was he like?

Jay Meistrich:

He was great. I think I originally liked him because he was very ambitious and he seemed to just love technology and told me about a lot of fun side projects he did in his dorm room and stuff, and I

Jamon Holmgren:

Like that excitement. It doesn't surprise me. It's hard to get him on this program for some reason, but I'd love to have him. He's so humble. He's like, oh, there's way more interesting people to talk to. That sounds right. Yeah, that's just Eli. He's more of a behind the scenes guy, but I really appreciate him.

Robin Heinze:

That sounds really interesting to me. I want to hear it from the behind the scenes guy, but

Jamon Holmgren:

Well, maybe you talked to him because I've

Robin Heinze:

Already tried five times.

Jay Meistrich:

I also, after he graduated, I traveled with him for nine months and basically spent 24 hours a day with him for almost nine months, and it was, wow. We got along very well. That was good.

Robin Heinze:

Well, that's good.

Jay Meistrich:

Yeah, I could see that. Yeah,

Robin Heinze:

The alternative would be pretty

Jamon Holmgren:

Bad, right? You cut your trip short, right. Yeah. So in case you haven't picked up on this yet, we're going to be talking about Jay's projects specifically about Legend List, which is a much more recent development. Of course, you can go to legend app.com and go find Legend List there. You can also find Legend State Legend Motion, and am I missing something? That's it for now. For

Robin Heinze:

Now.

Jamon Holmgren:

And then of course Legend itself, which is an amazing app that does kind of productivity stuff. So legend app.com/open-source I think is where you see everything.

Robin Heinze:

Yes, which we'll, everything. Yeah, we'll put all the links in, show notes.

Jamon Holmgren:

This whole obsession with performance goes way back as we hear with the sort of game type stuff. I've been building a game lately and I understand why now, because if you're not obsessed with performance, you quickly find yourself running it for FPS in situations that you shouldn't be. So yeah, I'm sure that informed what you do today.

Jay Meistrich:

Yes, very much. And I think specifically one of my key lessons was in games, you pre allocate everything because you cannot ever allocate anything during the Game Loop

Robin Heinze:

Or

Jay Meistrich:

You'll freeze everything. And so I guess the concept of memory management was always deeply ingrained in me.

Robin Heinze:

And then you started working with JavaScript people who are like, what do that?

Jay Meistrich:

Yeah, exactly.

Robin Heinze:

Well, which means there was probably a lot of low hanging fruit for you.

Jay Meistrich:

Very much.

Robin Heinze:

Yeah. A couple years ago, I guess it was. Now we had Taha from Shopify on the show to talk about List, which if you've been in React Native for a while, when you think highly performant, optimized scroll view, people probably think of Flash List in addition to now Legend List. But people are probably wondering just what's the TLDR? What makes Legend List different from Flash List? I'm not going to say better necessarily, but what makes it different?

Jay Meistrich:

So it, it's faster. In every case I've tested at least a lot of people using it are saying it's faster. I can't claim, it's always faster. I don't know. But every case I've tested has been, and that is one of the primary goals is just to be as fast as possible. Also, flash List does view recycling for performance, and that can do some really weird stuff. For example, if you have local state in your components and then you scroll that local state doesn't go away, so you have to reset it because it gets recycled. So there's some weird stuff there. So legend list that's optional. It makes performance better, but you have to opt into it. It can do weird stuff. Other goals are, there's a lot of important use cases that just don't work in flash lists. So for example, bidirectional infinite lists don't work and chat UIs are hard to make.

And then there's a prop in flat list, which is maintain visible content position, and that doesn't work. So that basically means that if you are scrolled to the middle of a list and then you scroll up and the items are different than you expect them to be, then the list will jump around. So we need to resize things above the screen in a way that doesn't jump the view, and that's pretty important I think. And then the other thing is just it's a lot smaller, so it's easier to customize for yourself or contribute to, it's about 2000 lines total. A lot of that's tight. Oh, wow. So it's not too big. So there's been a lot of really great contribution, which has been awesome. Recently there's been one guy specifically Michael Lanco, who's made huge contributions, and then we're now chatting every day and improving stuff. It's awesome. Open source is so cool.

Jamon Holmgren:

It really is. And I have to ask you, how do you keep a library small? It feels like that in itself takes a lot of effort. It's way easier to add a bunch of code.

Jay Meistrich:

I guess I'm just careful to not add features that aren't really important. And if they are, then maybe we can do it as a plugin or an external thing on top.

Jamon Holmgren:

Simple enough.

Jay Meistrich:

In Legend State for example, there's a lot of features that would be really cool to add. And so I made a plugin system so that users can add them after the fact. They don't have to be in the core.

Mazen Chami:

That's cool. So you didn't want to say it's extremely fast. Your doc say it's extremely fast. People on Twitter are saying it's extremely fast. What makes it, and I know you mean it, we talked about your performance background and all that. So you mean it, you're just, you don't want to say it, but what makes it extremely fast and what does it mean to you if something is extremely fast?

Jay Meistrich:

So for this, I think specifically it means that the user should never see any blanks or gaps in the list. It should just look like it's a scroll view and not care about the virtualization. So I think I mean that in two different ways. Basically, the obvious one is just make the list really fast, do as little work as possible, but then also we can optimize the perceived performance. So one of the things we do, for example with that is when you're scrolling really fast, instead of calculating the items that are currently on screen, we calculate the items that will be on screen in the next frame. So it looks like it's faster just by guessing what the user wants to see.

Jamon Holmgren:

I like that because performance really is about just do less. I was talking to Ton the Hermes guy and during our last interview, hopefully it comes out in order so people understand what I'm talking about. But the CPU on your computer doesn't run faster or slower based on what language is running because it's all compiled down and running on the same architecture, and it's all like, yeah, at the end of the day, it's doing the same stuff under the hood. So how do you make it fast? You have to make it do less. You have to really think through and understand the logic of what's happening there and find ways to cache at the right time or do little tricks. It's kind of smoke and mirrors a lot. Like games are where you're doing smoke and mirrors stuff, you can kind of anticipate what's going to happen and try to do things early.

Yeah, there's a lot of different techniques of course, and even just how you'd modeled the data itself, the state, what you're passing through can have an impact because there's some faster things and some less performance things. And ultimately when it comes down to it, you have to actually measure and care and iterate because as you said, just blindly using Recycle View isn't necessarily going to make your app better, faster, more performant, everything. And just to, again, use a game analogy, there's this thing in 3D games called Occlusion calling, which is essentially if there's something, if blocking your view of something else, it shouldn't render that thing behind it. But that comes at a cost too. You have to calculate, can you see any part of it, like the object behind, even if a little pixel is sticking out, you have to know that. And that takes some processing speed. And so you have to really be thinking about are you a top-down world game that you're going to see everything anyway, that's not worth doing, versus if you're walking through hallways, then you probably should have it on kind of similar vibe there. So a lot of measurement and a lot of experimentation, iteration. You start getting a little bit of a sense for that. Like a spidey sense. I know that I was doing some pairing with my brother Denton, who builds games. He's on Twitch a lot, as Dead Slap.

I was watching him build some stuff and he is a less experienced programmer, and I was like, I think what you're doing is going to lead to performance issues. He's like, yeah, I'm just trying to get it done. The other day he told me, yeah, I kind of abandoned that game. It was just hard to make it perform it. I was like, okay, well, can

Mazen Chami:

I ask you a follow-up question to that? So you mentioned how you're making it fast. What actually are the main optimizations that you're doing to give you that speed?

Jay Meistrich:

So the main thing that's slow in React is re rendering. So I have a motto which is basically three words, which is render less less often. And so we want to just make sure that we keep re-render to a minimum if you have to re-render the smallest possible amount. Because basically the way React works is a render runs your component, it computes all the hooks, it diffs the virtual dom, and then it commits the render. It's a lot of work. The compiler's going to help with a lot of that by just automatically making it render less stuff. But we can also do a lot of that manually. So Legend List does that in a lot of different ways, I guess. So the main thing is it renders, basically it creates absolutely positioned containers on the screen and then it renders items into those containers, and then as you scroll, it moves the container to the place where it needs to be to put a new item in and then renders the item there.

But we rendering the whole array of containers would be slow. So we have basically a signaling system so that when a new container comes into view, we just signal that container you need to re-render, and then that re-render with the new item at the new position. And so it skips all of the rendering, the outer list, which saves a lot of time. That's one of the things that Flat List does is basically flat list decides what items are in view and then renders an array of those items. And so that's just slower than rendering only the one container that changed. So that's the main thing. There's also a bunch of little tricks. For example, if we need to change a style, then it uses an animated value to change that so it doesn't have to re-render. So there's a bunch of weird little tricks like that too.

Mazen Chami:

That's pretty cool. You're giving the illusion of scrolling while not scrolling. I feel like you're just moving things around on the screen so that it's not rendering,

Jay Meistrich:

It's still scrolling, it's still a scroll view, it's still scrolling. It's just yeah, we are figuring out what items should be in your view and putting them there. So it's not using a regular flow

Mazen Chami:

Layout. And I feel like that whole, no, like rendering less is the important part to take from here. So that putting styles in animated value, I feel like that's the first time I've thought of that or heard of that concept to limit your re-render. That's pretty cool.

Jay Meistrich:

So we experimented a lot with using animated styles for the positions of the containers, but that ended up being kind of a no-go because it renders on a different thread, I guess. So it would sometimes render before the new item got there, or sometimes after. So it's better to stick with the react flow for that. But yeah, basically experimented with using animated values for updating styles very quickly.

Jamon Holmgren:

So you got me thinking about all kinds of different optimizations that could happen here. I'm probably going to hit you up afterward and ask, please, if you've thought of these, which I'm sure you have, but you're doing this at least right now, you're doing it all in JavaScript, which kind of blows my mind a little bit. Now, list uses some native modules. I'm a little bit foggy on exactly how they're using the native modules or what they're using them for. I think a little bit more about this, can you talk about list and I think the underlying recycler list view as well and what's going on there and what are the trade-offs of that architecture?

Jay Meistrich:

Yeah, so I'll caveat that I'm not an expert. I've just read the source a lot. And also I listened to your podcast interview of Taha.

Jamon Holmgren:

Well, yeah,

Jay Meistrich:

But basically what happens is it's recycler List view is all JavaScript, and that's doing the layout calculations and rendering everything and all the recycling. But then the problem you have with absolutely positioning things is React gives you an on layout event of the size of the element after it's already rendered. And so what'll happen is if you say the estimated size of the items is a hundred and then they're actually one 50, then you'll render two things a hundred pixels apart. And so now they're overlapping. And so then on the next frame, it'll put it in the right place. And then the other way is if it's smaller than you expected, you have gaps. And so flash list native component auto fixes the gaps for you. So even though you're rendering the rack components with gaps, the native code fixes the gaps. And so I think we may eventually also do that, but the goal first is to try to just not have gaps or have the gaps be so fast that it doesn't matter. If there's gaps, but they're off screen and you don't see them, then that's fine.

Jamon Holmgren:

Well, I thought you had to lay out with yoga

Jay Meistrich:

Belief flash list also. Absolutely.

Jamon Holmgren:

Positions. Okay. Okay, gotcha. So it's trying to do all this stuff in JavaScript as well. Why does that feel like it should be slow?

Jay Meistrich:

I don't know exactly why. I think there's just a lot of code in recycler list view. I don't fully understand what it's doing and why there's a performance difference, but it's much bigger. And I think the signaling thing we're doing as well as the animated values and stuff probably gives it a little bit of an edge.

Jamon Holmgren:

Right? Yeah. At first you had Legend State in there and then you eventually pulled that out, but I assume you have sort of a slim down version of some signaling Yeah, going on there.

Jay Meistrich:

Yeah. I made the first prototype on a train using Legend State, and then just proved out that it could work. And then I just built a tiny signaling system to use, so we don't have to bring in a dependency. It has zero dependencies, and I want to keep it that way.

Jamon Holmgren:

I like zero dependencies, and I think most developers do when they're bringing in a dependency, they don't want, they're inviting legend list in not all of its relatives. So they don't want to be maintaining everything. They just want that one thing. And I think for library maintainers, and I've been guilty of this in the past, adding a whole bunch of dependencies to your library, it's tempting, but you have a little bit of responsibility, especially if you want it to scale. If you are just building it for yourself and like, well, whatever, then that's fine. But we made this mistake, I think with Glue Gun, where Glue Gun, the CLI library, it brought on all kinds of dependencies, which there's some positives and negatives there. I started, I haven't finished yet, but there was a successor that was going to be zero dependency, which turns out to be kind of hard to do.

Jay Meistrich:

And on that point, I think I've tried to stay away from the native code as much as we can because it's a problem for a lot of apps. For outre platforms, you have to rewrite the native code for that platform. So I'd rather keep it JS as much as possible.

Mazen Chami:

Thank you for that consideration with Outre platforms, because yes, it can be a nightmare. And having to evaluate some packages recently for a client I was working on basically had me pivot completely and change my direction because of the cross-platform compatibility stuff. So I think that's very important. Now, on that topic specifically, are there any new architecture considerations to keep in mind or that you had to keep in mind while you were doing this?

Robin Heinze:

I'm guessing if it's just js, probably not,

Mazen Chami:

Right?

Jay Meistrich:

Yeah, I thought it would only work in new architecture, and it was inspired by Talk React Advanced about synchronous on layout. So I thought, oh, finally we can do this. But then once I actually built it, it worked fine in old platform old architecture too. So I think we're just working on some stuff right now using more synchronous layout using use the layout effect, and that seems to be a bit faster, but I haven't tested it against old architecture as much, but basically the answer is it works fine on both. Might be a little faster on the new one.

Jamon Holmgren:

So you're telling me we could have had this performance the whole time? I'm sorry. And Jay, where were you? Yeah, come on. That's amazing though. Yeah, I assume because the new architecture gives us more tools and more tools in the hands of someone who is as good a programmer as uj, that's just going to give you more options to make it awesome. So yeah, I could see that being the case, but hey, I mean, that's still a huge win to be able to support the old architecture for those who haven't been able to upgrade yet, still getting, and it truly is very, very close to just drop in replacement. There's very little changes as far as between flat list, flash list and legend list, right?

Jay Meistrich:

Yeah, it's a drop in replacement. There's a couple props. For example, recycling is opt-in, so if you switch from flash list, you would want to enable that.

Mazen Chami:

Well, on that recycling prop, I believe you call it recycle items, how does that differ from elaborate on what this actually does? We were talking about recycle recycler view earlier. Can you elaborate on this? Recycle items prop?

Jay Meistrich:

Yeah, so that makes it work. Basically how flash list works. So what the recycling does is it basically reuses all of the native views, and so it just does a lot less work because it doesn't have to dispose of the old one and then create a new one. It just updates maybe some text here and there. So generally you'll have better performance if you use that, but it also has some real big downsides because basically what happens is your render item function just gets called with a different item. And so if it contained any internal state, then you need to reset the state when it gets recycled, which can be kind of hard to track. There can be some weird stuff. If you had a drawer open and it gets recycled, you have to close the drawer or it'll look crazy. It could do some weird things with complex elements like videos,

Jamon Holmgren:

Especially if there's animations between states now you have to not animate between states because it should not. It should just be, yeah, that

Jay Meistrich:

Makes sense. Yeah, so it makes it just weird and hard and you have to do some wild stuff. So with things like videos or really heavy weight, when an item recycles back into view, you might see a flash of the old content before it switches depending on your app. So basically recycling is great optimization, but it can also do some weird stuff. And so we've tried to make it just as fast as it can possibly be without even needing recycling. And then you can optionally opt in if you want

Jamon Holmgren:

Performance, obviously huge recycling views, things like that. And this is really what everybody's asking for with our lists. So it's awesome that you're really focusing on this, but I want to know about other goals for Legend List. It's not probably just the fact that you can be performant. I mean, you mentioned earlier about making chat interfaces better. There's maintain scroll at end and things like that. What else? And bi-directional, infinite lists and whatnot. What else is really, I guess, talk about those things and anything else that you find important with building with a legend list?

Jay Meistrich:

Yeah, so the bi-directional infinite list thing is basically the thing I mentioned before of the maintained visible content position is if you pre-end items at the top of the list and you estimate that those are all a hundred say, and then you scroll up and it was actually one 50, it'll push your whole list down by 50 pixels and then that looks awful. And so maintain visible content position just makes that not happen, and it adjusts the things above you so that it doesn't move your positions. So that is very important for being able to scroll up infinitely. And so that lets you do bidirectional, infinite scrolling, which is important for chat, or if you wanted to make a calendar that can go infinitely in both directions, that kind of stuff. It's very important for a lot of apps. And then for chat apps, if you have two messages in your chat, then you need those two messages to be at the bottom. And so the way every other list works is you have to invert the list and put them in the wrong order, and then the messages appear at the top, but actually at the bottom because it's inverted. But then the way inverted works is it applies a transform scale of negative one,

Which Okay, gotcha. Which when I first heard that, it blew my mind, but that makes it really hard to do animations because you have to come out of the transform somehow. You can't do a shared element transitions, that kind of stuff. So that makes stuff go crazy. So the easier solution is if the content is smaller than the scroller, just add padding at the top. And so then the items are the bottom. So I've had a lot of people say, when are you going to support inverted? So I can make a chat and I say, just use the align items at bottom, and then that works. Sounds almost too easy.

Robin Heinze:

Yeah.

Jay Meistrich:

And then the maintain scroll at end thing is if you're near the bottom and new items come in at the bottom, it just keeps you scrolled at the bottom, which good for chat apps.

Jamon Holmgren:

Yeah. Well, I found that out the hard way. Again, talking about my game because that's what's top of mind. But I spent forever building lobby system and I added a chat to it and I was testing it and everything seemed fine, but I realized later I never actually tested it past the scroll. So I would test it like five different messages and everything was cool. And then I was actually in a lobby with my brother across the country and we were coordinating what we were going to do in this mission in our lobby, and it hit the end of the chat and all of a sudden it would just scroll to the top slowly like animated, and then scroll back to the bottom. And I have no idea why it was doing that. And it was super, super annoying and every message didn't matter. If you put it or they put it, it would do that. I was like, okay, yeah, I'm not working with React in here. This is all gado and GD script and stuff. Menu systems are where I really miss react. That's where it would be really nice.

Jay Meistrich:

Yeah, absolutely. Yeah. I guess in conclusion, there's a lot of important use cases that just didn't work in the old list, and I've spent three conferences asking people, what are your problems with lists? And then kind of tried to solve all of them. That's

Robin Heinze:

Smart, we should do it. Can we do that with keyboards next?

Jay Meistrich:

Oh yeah, we got to get Jay on

Jamon Holmgren:

Keyboards somehow. I don't know about that,

Robin Heinze:

But I'll tell you one thing that, can we get a keyboard, keyboard aware, legend list,

Jay Meistrich:

Legend keyboard. One thing that's a bit silly is I don't currently have any need for a list that is

Robin Heinze:

A bit silly.

Jay Meistrich:

Yeah, it's just it needed to be done, so I'm doing it.

Jamon Holmgren:

It did need to be done. Someone needed to do it, and we needed someone who had this performance superpower, which you more of an obsession, which is awesome. That's how most

Robin Heinze:

Superpowers are. I mean, yeah, usually what makes a superpower.

Jamon Holmgren:

So question for you, Jay. This is the last one we got to wrap up here, but is this ready to just drop in and start using right now? I know that as of the recording right now, you're basically preparing to drop 1.0. It's getting really, really, really close. By the time this actually airs, it should be out, but are you feeling pretty confident about that?

Jay Meistrich:

I am, yeah. Since it's in beta, I've had a few people dropping it into their apps and it seems to be going pretty well. I found a few interesting edge cases that we're fixing. So I think especially by the time this drops, I would say, yeah, it's ready. Just replace.

Jamon Holmgren:

Yeah, that's great. And you don't have to turn on recycle view if you don't want to mess with the complexity that brings, but if legend list by itself isn't doing the job, you have something kind of heavy in your cells and rebuilding that every time is just not doing the job. Then of course enable recycle items and actually go and do the work to make sure that they recycle properly.

Jay Meistrich:

There's also a set of hooks like use recycling, state use recycling effect that can help you with resetting the state. So use recycling state. You give it the initial state, it'll just automatically reset to it when it recycles.

Jamon Holmgren:

Oh, now that's amazing. So that would actually save a lot of headache, I guess. Yeah, animated stuff or things like that could be a little bit of an issue.

Jay Meistrich:

And then use recycling effect. You just close the drawer or whatever, and so that'll just get called whenever it recycles and help you clear the state out.

Jamon Holmgren:

Yeah. Yeah. Okay. That makes sense. But if, if you have no animations, and especially if your cells don't change much or they're just informational, it seems like a no-brainer. Really. Cool. Awesome. Well, thanks so much, Jay. There's way more that we could talk about Legend State itself, your sync system, which I think is amazing. And of course, legend Motion, which a lot of people don't really know about, they only know about reanimated. There's just so many things that you've created that are really cool, and I appreciate you being in the React native community and helping us out with all these things.

Jay Meistrich:

Oh, thank you.

Jamon Holmgren:

And you're on Blue Sky and Twitter? Yeah. Your

Jay Meistrich:

Handle is on Twitter. It's J Meistrich, the letter J, and then my last name. And on Blue Sky, it's J-J-A-Y-Z us. Perfect.

Robin Heinze:

Yeah, I love that Blue Sky lets you do that.

Jay Meistrich:

Yeah,

Jamon Holmgren:

It's great. I got that domain years ago. Yeah, I see you at conferences all the time, so definitely keep an eye out if you're at any React native or React conferences and sometimes others, you're big on local first, so there's some conferences you're going to for that. I would encourage people that are listening to this podcast say hi to Jay Jay's awesome. Really, really loves to talk about tech and talk shop. In my experience, he's always willing to hear your use case, loves to hear how his stuff is working within your app.

Jay Meistrich:

Yeah, definitely.

Jamon Holmgren:

Yeah. Awesome. Well, I think that's all we have time for today, so we will wrap things up. Robin, do you have a mom joke?

Robin Heinze:

I wouldn't call this a mom joke, but it's a really great insult. The next time your friend's being a doofus, you're like a software update every time I see you. I think not now.

Jamon Holmgren:

That's a good insult. Only my nerdy friends are going to get that, which I guess that works.

Robin Heinze:

I don't know. Everybody has to do software updates. Maybe

Jamon Holmgren:

That's true. Yeah, that's my mother-in-law. Alright, we'll talk to you all later. See you next time. Bye bye.

Jed Bartausky:

As always, thanks to our editor Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red, check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.