Radix UI with Chance Strickland

24:25It's like, that's kind of a, it's a weird thing. We weren't selling it. So I didn't really understand like open source business models at the time. But yeah, they brought me on and it was a great experience. I got to be the full-time maintainer of Reach UI for a few years. Then the pandemic happened and the sky fell. The entire funding model of the company behind Reach UI was in-person training and that dried up like very quickly. So they unfortunately had to let us go. And I was sort of off in La La Land looking for my follow-up gig. And thankfully right around that time, a company called Modules was working on this new library called Radix.

25:03And they knew what I was working on because they looked at Reach UI a lot for inspiration on the design of Radix. And so the code that I was writing was very visible to them. And as soon as they found out I was laid off, I basically had an interview within a few weeks because they wanted me to come work on Radix. So that was my in there. That was really great. And then yeah, it's one of the early maintainers and builders of the Radix project. And then fast forward to whenever it was that WorkOS acquired the Radix team. I actually went off and worked for a different company, helped build Remix.

25:35And then that got acquired by Shopify and a lot of other stuff happened in my career, but ultimately came to WorkOS and they were like, hey, why don't you maintain Radix again? And I was like, that's cool. It's like, just came full circle. So anyway, that's my spiraling, rambly story about how I got here. Very cool. Since you mentioned it, I'm looking at ReachUI and I hadn't used this. I've been around React forever, but I've not used this before. I was immediately drawn to the component component and just looking into what that is. Oh, yeah. So that's a funny one, too, because component component.

26:06Well, it's a ridiculous name, but Ryan is kind of a ridiculous person sometimes. So I really enjoy his sense of humor. But yeah, component component was interesting because what it essentially is, this predates hooks. So you can sort of think as component component as the way to sort of like access contextual logic from parent components and child components before the hooks world, right? So prior to hooks, there were a couple tricks we had in the React world to essentially like implicitly link two different components. And what I mean by that is like the traditional way to feed data from one component to another in React is passing them via props, right?

26:47Like we all just pass props along. But when you have these like highly coupled components, like a select, right? Like a select is always going to be coupled in some way to the thing that opens it. And it's going to be coupled to the list of select items, right? A lot of times components are just inherently linked together and props are clunky because you end up having to pass down from the top component down and like essentially prop drills, the term we came up with back in the day where you're just like drilling props to multiple levels. And with highly coupled components, it was just simpler not to have to do that and be able to access contextual data from some parent component.

27:20And so there were different patterns adopted for this higher level components where you could basically create a wrapper function that wraps one component and then just passes along certain props from some parent. That was fine, but it was a little hard to follow what was actually happening in the code. You would end up with like 20 different higher level wrappers and then peeling that onion back became pretty tricky. So this was all pre-context. So React context changed a lot of this, but also So React Hooks obviously changed a lot of this where you could use the context directly without having to, again, prop drill.

27:53But before all that, Ryan decided he was going to try and solve this problem in third-party land, and he came up with Component Component, which is essentially this higher-level component that allows you to access the lifecycle methods of a React class component or state-setters of a parent component in children. So yeah, it was kind of like his initial idea of how to solve this problem before Hoops came out and solved a lot of these problems for us. Tired of babysitting autoscalers and overspending on cloud costs? Meet Thoris, the platform that makes engineers heroes to their finance and business leaders.

28:28Thoris intelligently manages Kubernetes clusters, automatically right-sizing and scaling workloads while preventing downtime from traffic spikes. It anticipates usage and capacity needs, so systems stay fast, reliable, and efficient, without constant tuning. Teams using Thoris cut cloud spend by 40-60%. Thoris predicts compute and GPU demand before it happens, keeping performance smooth and costs in check. Stop wasting compute and guessing your resource needs. Let Thoris handle your autoscaling, so your teams can focus on building. Find out how much you can save with Thoris. Visit thoris.ai and try our cloud savings calculator.

29:10Is your AI model taking weeks to train? Or is it too slow for real-time inference? FixStar's AI Booster is the acceleration platform that solves both. AI Booster automatically analyzes and optimizes your entire AI pipeline. The result? Dramatically faster training, up to 5 times faster, and compute costs slashed by up to 80%. trusted by major companies, including Sony Honda Mobility. Stop waiting on your hardware. Visit FixedArs.com to learn how. When I was looking at it, it gave me the vibe of context. Like that, just seeing the set state being passed down is kind of what gave me that, I suppose.

29:50But also on this site, I see that it's copyright React training, which the company you worked, and then they kind of, those folks went on to do Remix, as you said, and you had some run-in with that. And so I have to ask, given that this is a React library and Remix's future, as they've kind of started talking about their plans of potentially not going with React for their rendering. I don't know if you had any thoughts or things on that. Just like I think about it in terms of like, there's a lot of these mature component libraries now that you won't be able to use if you're using the new Remix.

30:26I'm not trying to like make you say anything controversial or anything. I'm just curious if you had any thoughts on that. Sure. Yeah. And I try not to be too controversial. I don't have a lot of hard opinions in this world. I have opinions that are, what is the saying? Strong opinions, loosely held, something along those lines. Anyway, so I try to keep an open mind to most things. And same thing goes for this particular thing. So yeah, a little context here. The Remix project started shortly after the pandemic when they had to lay the team off and we're out of work and they were like, well, now's the best time we're ever going to have because we have all this free time.

31:00What are we going to do with it? Now's a good time to work on this framework that we've been cooking around in our heads for the last several years. Because Remix really was a series of ideas that Michael and Ryan just had, but never took the time to build it. And now they had the time. And so they thought, why not build it now? And so, yeah, it started as a React framework and solved a lot of problems that they found lacking in other solutions at the time. And yeah, eventually I joined the team and it's a small, scrappy little startup trying to work our way to the top. And yeah, we built a framework that caught a bunch of people's eyes, got a good amount of users pretty quickly.

31:38And a lot of people really liked the model that we had provided. and they liked it so much that ultimately it was acquired by Shopify. And Shopify has continued to invest in it and build it out. And it's been through a couple of different major versions at this point. But as you might know, or listeners may or may not know, at React Conf, I want to say it was last year, the year before, Ryan got on stage and told everyone that Remix was taking a little nap and the world panicked. Everyone thought, oh my God, they're killing Remix. This is like React Router v4 all over again. What are we doing here?

32:14And what he actually meant, it may have been a little clunkily delivered, but it wasn't that they were killing Remix. It was that Remix needed to fundamentally change. As much as they really liked the model they had built on Remix, Remix itself as an idea could have been a lot more. But what they didn't want is to pull the rug out from people who were using Remix. They also thought there was still a lot of value in the model that they had, and they wanted to build on that. The thing about Remix, though, is that it was built entirely on top of React Router. The heart of any framework really is the router.

32:51And React Router was sort of the underlying tool that powered most of what Remix ultimately was. So the entire routing system was React Router. And over time, they started adding new features to React Router that were originally Remix concepts to the point where at some point you looked up and you said to yourself, React Router just looks like Remix, except for there's no server. It's just a client-side library, but the actual APIs look a lot alike. And at that point, what is Remix even? Remix is essentially a compiler that allows you to build a React Router app and target a server and a client.

33:29Why wouldn't React Router just do that for you if it's already got all the other features, right? And so essentially they just ported over everything that was in Remix into React Router and started referring to React Router as a framework because it was, it was suddenly a framework, superpower framework, and it looked basically the same as the prior version of Remix with a few new major changes. So React Router V7 was essentially what Remix V3 would have been. But now you had a naming problem and naming things is hard in this field of work. So you had a naming problem, you had a messaging problem.

34:02So how do we solve that? Well, again, I go back to the fact that they still had a lot of really cool ideas for Remix. And I just want to be clear about something really quick. I had left the company at this point, so I don't have any like inside baseball knowledge of what happened at the point when they decided to do this fork in the road. So I'm just making guesses alongside the best of us. You know, I know the guys still, so I know a little bit, but I don't have any special knowledge here. So I'm just riffing. But what I sort of feel like happened is the Remix name and the Remix idea, the underlying idea, not the implementation, but just the idea of building this like web first framework.

34:42That's ultimately what it was like the underlying selling point of Remix from the very beginning was to build a JavaScript framework that really looked like the web. I use web primitives under the hood. It used the fetch API across the client and the server. It used abort controllers. It used HTTP as a design basis across the board. So it really did lean into WebFIRS principles. And that spirit could still be there in something that they took and just sort of rethought from the ground up. What does the web have on the front end that we're not really utilizing to its fullest potential? Well, it has web components, right?

35:18Again, no special knowledge here. I don't know if they're going to build Remix on top of web components. So they may or may not, but this is just me like pondering, like what could the web provide you that Remix v1 or v2 didn't provide you? And how can we build on this like underlying idea? And the new version of Remix could be whatever that is. And yet at a certain point they came out and said, you know what, we are going to really rethink everything from first principles. We are going to even rethink React because while they obviously love react they built on it they stake their careers on it you know like react said what is like 10 11 years old at this point 12 years old you said 2013 so yeah like they're 12 13 years old something around there it's been around the block for a while and it's still very valuable but there's a lot of things we've learned since then that maybe there's something they could take forward and again no special knowledge i don't actually know what it is they're going to build but here's the thing i know about michael and ryan is they're always kind of like one or two steps ahead of where you and I are.

36:17And every time I've ever doubted them, they've proven me wrong. So we will see. I'm very excited to see what they build. And I think they got the chops to build something really cool. So TBD on that. Yeah, totally agree. And I think it's great that they're remixing it to use the term and rethinking from first principles, because if you just settle, then that's what you're stuck with. So I'm very excited about it. And I hadn't considered that it could be web components and not that it is, you know, but if it were, it really might not be, I don't know what their front end library of, I do know it will be composition based because everything, like I said, that's like the underlying model that sold react in the first place was composition first.

36:58And so I know, I do know for a fact that they put high value on that. And whatever we see, we'll have a, a very composition driven API for building components. So I'm stoked to see what it is. Same. Yeah, I'm looking forward to it. Always good to see new innovation in this. Now, getting back to Radix, I did want to ask about something that I actually don't know a lot about. Even though I've used Radix a lot, when the topic of Radix comes up, inevitably ShadCN comes up. Can you explain the relationship between Radix and ShadCN and kind of how that came to be? Yeah, so ShadCN, for those who don't know, is kind of a design system builder or a component builder of sorts, where there's a component library that you typically would install from NPM.

37:45In ShadCN, originally, when it started, you would go to the website, and it would have this giant list of components, and you would click on, you know, like a tabs component or something in the docs, and it would show you a bunch of code that you needed to copy and paste and drop in your app, which was a slightly different approach, right? You didn't install anything from NPM. There might be a few underlying dependencies, but it was a copy-paste code approach. So it was very old school in that way, which may have seemed counterintuitive. But for something like a component library, it was actually a really powerful idea that you should just own your component library.

38:19You should own the code because libraries come and go. They may or may not get neglected over the years. There may be limited capacity for you to customize certain things or add functionality. But if you own the code, it's way easier to make tweaks to the code. And for some reason, people are terrified of going into their node modules folder. So that's not an option. You got to take it out of the node modules and stick it in your source directory and just own the code. And so that was a sort of novel concept in the React ecosystem at the time. And the ideas just sort of took off. And then over time, it got a lot more sophisticated.

38:54They got a lot more components. And then they ultimately built like a CLI tool that you could use to just drop the, so you didn't have to like manually copy paste things. You just dropped them into your project with a script. And now they have a bunch of tools around like LLM usage that I'm not super familiar with. But the relationship that you're asking about is essentially that most of the components in ShadCN are abstractions on top of Radix. ShadCN does provide a lot of other things for you. It also built on Tailwind. So everything you download or copy from ShadCN is going to be built on Tailwind classes.

39:32So it expects that you use Tailwind in your project. And yeah, like I said, it's built on top of Radix components as well. So if you go and look at like a Shadzian dialogue, that's going to be under the hood, a Radix primitive dialogue that comes with a bunch of pre-baked styles using Tailwind classes. Okay. So could you think of it as like another theme? I guess I'm trying to... It's a different approach to trying to solve a similar problem as Radix themes. Yeah, I mean, certainly it, Radix themes, the selling point is you want to be able to bootstrap something quickly. You go grab this thing, don't have to think about styles and then you can theme it, right?

40:11Shadzee and Dust provide a similar interface, except for, again, it's not a library and the theming options are whatever you are presented with in Tailwind. And then from there, you can sort of manipulate your Tailwind config and it will impact how all of your Shadzee and components ultimately look. But since you own the code, you can also go in and make more granular changes that you might not be able to with a library first approach. So yeah, it is a different approach to solving a very similar problem. Got it. Okay. And is there any collaboration between the two teams on these two working together?

40:46Not at all. But if anyone working on ShadCM wants to come help us out, let us know. I've been open to it. But yeah, waiting for that phone call still. Okay, so this is making more sense. as I've been kind of experimenting with vibe coding a little bit and making an app that is using shad CN. But then when I go look at my package JSON, it's all Radix. And so it's because it's using the CLI to just put those components in using shad CN CLI, but they're Radix components. And then it has their styles and their setup. That's right. And it's not just Radix. There's other dependencies in the mix too for certain components.

41:22They come baked with some icon libraries, I think. So yeah, there's a number of other libraries, But essentially, Shadzian is building on top of other libraries to provide a slightly higher level of abstraction so that you can grab a component really quickly and get off to the races. Very cool. So where do you see Radix going? Do you have big plans or big changes that you foresee coming or do you feel like it's fairly mature? so i think for radix primitives it's fairly mature there we have a wide adoption at this point and as we talked about shad c and is built on top of it and it is working very well for a lot of people in production and there's not a lot more that we really need to build now that being said there are additional primitives people have asked for and things that we are currently building so there will be new primitives that pop up from time to time but the overall suite of tools is pretty mature.

42:18And so Radix as a whole, though, again, Radix is sort of a grouping of different things. It's not just one thing. Primitive is a piece of the puzzle, but there's a bigger puzzle at play. And when you start putting that together, I think the question gets very interesting. What is Radix? What does it become in the future? And the way that we've always thought about Radix is it is a toolkit for building on the web. That's like very high level, how we think about Radix. Everything else from my perspective is an implementation detail. The implementation of what do people need to reach for to build for the web?

42:57And I think there's still a lot of opportunity in answering that question. And it's something that we're actively discussing at WorkOS. So I think we don't have like a very firm answer for that right away. Like I said, it's an active conversation and lots of really great ideas that we've been noodling on. And we've got some experiments internal that we're working on to try and like proof of concept, some of these ideas. So it's very much still baking. All I will say is that the work we're doing, I think is pretty exciting and it'll be really cool when we finally get to roll something out to people to see what that might look like.

43:29But I think there's still a lot of exploration to do in answering that question. What are the tools people need to build for the web and how can we give you as, provide as much value as we possibly can to fulfill that goal. So what that actually looks like, TBD. But that's how I think of Radix evolving over the years. I mean, the web platform itself, like I said, has changed so much, but also how people build with LLMs and different AI tools, basically allowing you to drastically shortcut build times. And so like the interface for actually building things with LLMs is very different than how we've done things in the past.

44:02So I suspect we'll be leaning on that to some degree. But yeah, that's just kind of how I think about Radix. And I think everything that we do moving forward will be in service of that bigger picture. Very cool. You said that some new component or some new primitives might be coming. What goes into a decision to like decide to add a new primitive to Radix? Sure. Well, we build our entire design system at WorkOS on top of Radix. And so we see very intimately. Like we have a very, our culture is very big on dogfooding. So like pretty much any tools that we build for customers, we try and also use ourselves.

44:38And that's also true with Radix. Like everything that you use as much as possible is built on top of Radix. And so that gives us a really useful insight as to what might be missing, what gaps there are that need to be filled in Radix. And so we can see very quickly what Radix is good at and what gaps there might be. And like, how can we fill those gaps, right? Like, so we are, for example, we're an authentication company for the most part, like WorkOS is a lot more than that, but a lot of our tools and services around authentication. And so, you know, as we're building components out for the WorkOS dashboard or the admin portal, we noticed that, hey, we are reaching for other tools or we're hand rolling our own component for this thing, right?

45:19One example being a one-time password field. You know, we've all seen the one-time password field, which is essentially six many inputs that all accept a single number. And then there are certain behaviors that are expected when you encounter one of these, like one of them being if you paste into a single input, it actually pastes in all the inputs because it's interesting because it's really one input. It's just visually six different inputs. But that also kind of comes with like when you visually alter an input, maybe there's like different user expectations for how things behave than a normal input.

45:51So then you have to think about, okay, what happens if the user clicks on the fourth input and not the first one. You have to think about what happens if they focus that fourth input and then they try and paste a code. Do we start from the beginning or do we start from the middle? It's weird because in a single input, you can't just put the cursor four places to the right. It's one input and there's only as much space as you've entered white space. So there's different things you have to think about. And this is what I talked about earlier, when you peel back the onion of something that seems very simple, it's actually you have to think about a lot of different things.

46:22And so we looked at this and we said, we don't have this in Radix. Why? Like, why don't we have this? It's pretty complex to implement. Well, it would provide a lot of value because tons of apps use this pattern. Let's just build one and put it in Radix. And that's what we did. And so now it's still in sort of like an early pre-release phase. I think it is the API is still in flux somewhat. So we've exported as an unstable prefix, but it is still documented. So you can go look at the Radix docs today and see our one-time password field. And then we also recently rolled out another auth related components.

46:54Password toggle field, another interesting one. This one was a fun one to build. Also, it looks very simple on the surface. I will say it is a little simpler than the one-time password, but it's still, I think, pretty useful. So you've got an input. Everyone's seen this pattern. It's for passwords. I may or may not want to be able to mask the password. So you want a little toggle button to turn the password visibility on or off. And so it's fairly simple and straightforward, but you have to think about things like focus management, cursor position when I want to toggle the password on and off because you don't want to have to keep tabbing back and forth, right?

47:26Or if I click on the button, I might not want to move focus to the button because I'm still typing the password, right? So little things like that you want to think about and we just hide all that logic away. So all you have to do is drop it into your code and customize it to fit your needs. And then we have a couple we haven't shipped that are also author related. There's another one that I'm working on now. It's a password strength indicator. So we've all seen that too, where you've got a list of different requirements that you need to fulfill. And if your password is not at least, you know, eight characters or whatever, it yells at you.

47:54And as soon as you satisfy that need, it stops yelling at you. So we're building that out. And yeah, we have a couple ideas for new author related components. And then there's, you know, there's some other non author related components as well. Just any sort of gaps we identify in internally. And also like we get ideas from the community as well. And I know there's lots of components that people in the community have asked us for, and we've been not building them for a while. So, you know, we hear you, but I'll say is we've got some other stuff coming. So, you know, keep your eyes open. Combo box, I imagine is one.

48:23No, don't, don't even say the word. I thought that you had a really good explanation of as to why that might not be affirmative. It's hard. It's hard to do right. That's the answer. You know, it's been brought up a number of times. And at this point we kind of have, we joke about it a lot in our internal meetings, but you know, I guess I keep your eyes open. Never know. Awesome. about that. And yeah, I just wanted to say on, you know, the auth specific components, like particularly the OTP, that field, like it is so critical to get that right. Like just as a user, if it's wrong and if I'm trying to like, if I mistype something and I have to like hit backspace and it's not going back to the previous one, like I'm just completely annoyed.

49:08And so that is something that is so important to get right. But also it's something that's super important to get right, not just for humans, but for machines. And I'm thinking specifically like password managers, being able to automatically fill that out and detect when that happens. Like now one password just kind of like fits it in and it goes. And if that doesn't work right away, like that's something that is real friction for real users all the time. Absolutely. So, and it's not just one password. People use other password managers and they'll have different mechanisms for handling this thing and say, yeah, we have to test that and make sure it works and not only works with the password managers, but across different browsers and their password manager extensions has to work on mobile.

49:47Like another thing, if you're on, I'm sure Android has this too. I use an iPhone, so, you know, it's probably everywhere, but you know, when I open up a page that has that one-time password input, the second I get a text message, I get a little screen that says, here's the code. And then you press that button and the code just auto fills and auto submits. We have to make sure that that works too. So yeah, there's a handful of like little features that users expect and actually implementing them is a little bit more complicated than you might imagine. Yeah. This is getting into the weeds a little bit, but I'm just curious, like, does it come down to it actually just being one field or is it like a specific name or specific attributes that might be on that text input?

50:27Yeah. So different people have implemented this differently. The way we do it with Radix is it's actually implemented as six separate inputs. There are a few libraries I've seen that what they do is they have a single input, but then they visually hide it and then mask it with these things that look like inputs. But then that sort of constrains you a bit because now it has to – you can only focus at one – it's one input, so that input is the thing that always has the focus, right? And when you enter one character and you move over to the right and you have different characters, when they visually look like inputs, You want to be able to see the focus on the currently active input or like what I perceive as the input, right?

51:06So it's a very clever approach. And I think there's actually a lot of merit to building it that way because it does remove a lot of complexity. But there's also some like really weird nuances and edge cases that you have to consider when something looks like something to a user, they expect it to behave a certain way. And trying to mask that behind another element that looks and behaves sort of differently to the user comes with a little bit of potential friction. Yeah. There is one other question that I wanted to ask. Inevitably, everything devolves in 2025 down to AI. And I'm curious, like, how AI has affected Radix or has it?

51:46You mentioned it being popular with LLMs, for example. I think a big part of that's probably V0 and ShadCN building components out of that. But have you seen any other effects in this age of AI on how you build these components or how they're consumed or how you think about them? Oh, yeah, we think about this a lot. And I would say that the composition model in Radix, I think before we were even thinking about AI, it turns out that LLMs really do naturally work well with composition first APIs. And so it's really easy to ask an LLM something or go to chat GPT and ask it for something to build you a React component.

52:29And a lot of times it's going to build you something that looks a lot like Radix because it's just the core composition model of React. And so I think just because we followed that pattern really closely, LLMs are already kind of like naturally good at building things out that either use Radix or look a lot like Radix. But in terms of how we can sort of build on that, yeah, we have a lot of different ideas for that. You know, we want to make sure that you have like a cloud config file in your code base that sort of helps the tooling understand Radix a little bit more in depth, understand how you've implemented it in your own code base.

53:06These are different things that we are probably going to add in the near future. They are things that we actively talk about for sure. And then going back to like my bigger picture question of like, what is Radix at the end of the day? like a toolkit for building on the web. Okay. How do people build on the web? Increasingly, it's going to be using AI, right? That's only going to increase over time. So if that's how people build for the web, how does Radix fulfill that vision? Of course, it's going to be AI to some degree. You know, what does that look like? Not exactly sure yet, but it's something that we think about a lot.

53:43And again, a lot of ideas that we are currently baking. Yeah. I hate being vague. about certain things, but I also don't want to say something and people get excited and then it doesn't happen. And they're like, oh, you said this thing. And I don't know, like we're just cooking. Yeah, no, that's great. And I think that that's enough right now. You know, we don't know where this is all going to go in a year from now. And so just knowing that it's on your radar as a maintainer and you're thinking actively thinking about how people are going to interact with these tools and how people are going to build using this toolkit.

54:14I think that's comforting for sure. So, yeah, that's a great answer. Finally, is there anything that we haven't talked about that you want people to know about Radix? Oh, yeah. So one thing we've been doing, my coworker and I, Michael Chan, have been doing a roughly weekly, bi-weekly stream. We're still trying to figure out an exact schedule, but we started streaming some just like, what do we do with Radix? Like, how do we work on it? It's very, very new. So we're still figuring out the format and all that. But it's been a lot of fun. And I think it would be really useful for people to like just if you're really interested in seeing how the sausage is made, and peeling back the onion or whatever other food analogy you want to make.

54:52But if you want to dig into the weeds of Radix with us, that's your opportunity, I think, to really do that. And also, even if you don't care about Radix, we talk a lot about like what goes into maintaining a popular open source library, because I think that in itself is very useful for people to have context. A lot of us just think of open source as this thing that you get for free and there's not a real person necessarily behind the screen actually delivering and working on this for you and giving you a lot of value for zero money. So I think it's really useful to just sort of understand a little bit more about what goes into it and maybe give you a little bit of empathy for the folks who are building it.

55:30I'm not like sobbing about the situation. We're doing fine, you know, but I do think it would be better for the community if everyone sort of like understood what goes into open source. Yeah, absolutely. I love that level of transparency and just like thought process, you know, getting into the mindset a little bit is a very eyeopening, not just for like from a maintainer's perspective or from, you know, a human perspective, but also just seeing like, like you said, how that sausage is made or how the, you know, peeling back the onion, whatever it is very valuable just to your own learning and growth.

56:01Well, very cool. Chance, where can people find you on the internet? They can find me on Blue Sky is primarily where I spend the majority of my time, though I am trying to spend less time on the internet in general, aside from the time that I work on it. But yeah, chance.dev, which is my website and also my Blue Sky handle. So that's probably the best place you can find me if you want random thoughts on component libraries or food or whatever thought pops into my dumb brain. Awesome. Well, thank you so much for spending time with us today and we'll catch you next time. Yeah, thanks. This is awesome.