00:00 Hello, everybody. I am so excited to be joined by my friend Jenna. Jenna and I have been friends for a couple of years. I actually, I think, yeah, we met through the Remix community years ago. Jenna was one of the early adopters,

00:16 and we had a meal together in London a couple years ago. And looking forward to the next time we can do that. But yeah, Jenna, I'd love for people to get to know you a little bit. Could you introduce yourself to the audience here? Yeah, sure. My name is Jenna. I am a front-end developer.

00:35 I've been doing it for far too long. I don't want to give away my age, but yeah. I previously worked on the Radix team at Modules, so building out the Radix primitives. And yeah, currently working at a company, AI company.

00:54 I think everyone's having a go at AI at the moment, aren't they? Yeah, that's me. Very cool. Yeah, that's kind of fun. I didn't realize that you were currently working at a company doing AI stuff. Do you mind elaborating on that a little bit? Yeah, sure. It's a company called Scroll, Scroll AI.

01:13 And they're trying to create a bit like Notion, but for publishers, journalists, basically, to generate that they curate a lot of content when they're trying to write articles.

01:31 So it's kind of a platform where they can just transcribe content and curate clippings and plan their journalism before they write it. But it's really fun, because I mean, I haven't worked too much on the AI side of things,

01:49 but there's a lot of research that goes into the right AI tools to use for the quality that we need. They're really concerned about polish in the application. So for me, it's really fun trying to do the micro-interactions and things like that. And the bosses, they've got a really keen eye.

02:08 They're always giving me micros. That actually, as a front-end developer with such a keen eye for micro-interactions and good UX yourself, it's probably a little bit refreshing for them to say, hey, actually, I want this UX to be better, rather than just throw it together and ship it.

02:28 We've got other stuff for you to do. Yeah, 100%. I think when I worked at modules, they were very much like, these components take time to get right and all that stuff. So you could sit and really spend ages on these things. But generally, when I've worked in product companies, it's been very much like everything

02:46 needed to be done yesterday. Yeah, I've not worked at a product company that's this focused on the detail. It's really fun, refreshing. It's nice. That is super cool. I'm kind of curious about the product a little bit.

03:04 So it sounds like the intent of this product is not to generate articles, but rather to help humans who are writing the articles. Yes. Is there anything that, has that been a challenge, to make sure that people don't abuse it, to just write the articles for them?

03:24 I think, potentially, in the future, the company might go down that path of actually helping them to write the article. You can write the article in the platform. But right now, it's so early stages of the startup. They're trying to focus specifically on journalism and curating the content. Also, there's a fact-checking piece

03:44 that we want to do eventually. Oh, that's cool. Yeah. So a lot of journalists, obviously, create a lot of content. And they usually do it in Word Docs and Google Docs and things like that. And there's just stuff all over the place. So when they send them to fact-checkers, it's quite hard for the fact-checkers

04:01 to go through it all and make sure everything's true. So yeah, this is kind of, hopefully, going to be helping them for that phase, the planning and preparation phase, fact-checking phase. And maybe one day, yeah, they'll be able to write it there, too.

04:19 But that's just not our focus at the moment. I think that is awesome. A lot of people are concerned that AI is just going to be writing all the articles, and it's going to be low-quality stuff. But it sounds like your company is using AI to increase the quality of articles

04:35 and just increase the quality of what humans are writing and maybe even the throughput as well, which is awesome. I am so glad that you got that from that, because, yes, that is exactly what their main goal is, that there's so much content out there now that's

04:52 just rehashed AI content. So yeah, we're losing that quality in the content we're reading, because publishers can't keep up. They can't compete with all the articles from AI. So the idea is to create a platform that

05:11 can help them write high-quality content faster, I guess. So yeah, it's something I believe in. I think it's a nice idea, and it's fun to work on, because the keen eye for quality is always fun for me. That's super. I was doing some keyword searches for something else

05:32 that I was working on. And I found this website where you could do a search for how frequently do people search for this thing. And then as you continued in there, it was like a wizard sort of thing. You got to this part where they're like, OK, now, just click this button, and we'll generate an article for you that is optimized for this keyword.

05:52 And I was like, no, no, no, no, no, no, no. We don't need that. Please, this is awful. Don't do that, please. Yeah, I'm starting to really notice when things are generated by AI now. I've done it myself in one of my blog posts where it's like everything has got a colon after it.

06:11 And it's like, oh, the titles have got colons in. That's totally AI generated. So I have to go back to one of my generated titles in one of my blog posts. And I'm like, oh, I've got to take that colon out now. I've learned my lesson. There is actually a platform called Blog Recorder,

06:29 this app that a buddy of mine has put together. And it's really cool. You just record your voice in the app, and then it will transcribe it, send it over to AI, and AI will take those disconnected thoughts and turn it into a cohesive blog post for you.

06:45 And that, I think, is a really great solution to this because it tries to preserve your voice. And of course, it doesn't publish it for you automatically, so I will go through it and make changes. But I found that AI can be really helpful in giving me a skeleton that I can then change.

07:05 It's easier to, rather than looking at a blank page, I've got a bunch of text that I can modify. So yeah, it's an interesting future with AI-generated content. I've been doing it the other way around. So I'll write a blog, and it's just a mess. I've said too much. I'm way too wordy. So I'm like, AI, tighten this up for me, please.

07:25 Make it shorter. Make it easier to understand. So yeah, I love asking AI to adjust it for a multilingual audience because I think, as a native English speaker, we have a tendency to use more advanced words and complicated language. And it's really interesting watching

07:44 how AI really simplifies the words I use and makes it just easier, more accessible for everyone, I guess. I love it. Yeah. See, AI can be used to do good things, too. Honestly, I think most of the time, for most of us, we are using AI to do good things. And I think it's cool.

08:03 It's a really great tool. Yeah. Have you used it much when you've been coding? Yeah, constantly. And I've bounced around a bunch of different AI assistants as well. I have no loyalties to anybody. So I started with Copilot. I use Codium.

08:22 All of Epic React videos, I'm using Codium in those recordings. And then I've recently switched to Cursor. It's like a fork of VS Code. And it's just, wow, it's a really, really powerful assistant. So I'm excited about where these are going.

08:41 Haven't quite taken that leap yet, but I'm getting FOMO drastically. I might have to go that route. I've been using Super Maven in my app. Oh, yeah. I use Super Maven as well. And it's fast. It is so fast. I'm loving it, especially when I'm building Token Army at the moment.

09:02 There's a lot of manual typing, like copy and paste stuff. And I can just do a couple of the lines and just hit Tab, and it auto-completes everything for me. And I'm like, oh, that took me two seconds instead of half an hour of manually tweaking bits. Yes. It's great. Really fun. Fantastic. It really is.

09:21 Lots of people are either hesitant or think it's not good enough yet. And I find that even an intern that isn't good enough yet can still be valuable if you give them the right direction.

09:37 And so, yeah. Everyone in my feed seems to be expecting it to output perfect code. And I'm like, well, I don't really see it as that. Something that might have taken me half an hour to figure out now only takes me five minutes.

09:55 I still have to tweak it and hold its hand a little bit. But it's totally sped up my productivity. It's crazy. And it's exciting. Who knows where it's going to be in the future? Hopefully, it remains the assistant. I should say that. So Jenna, you've worked on a couple of cool projects.

10:19 You mentioned Radex. I would like to know a little bit of the history of Radex. Lots of the people who are listening, if they haven't used Radex directly, they are using it indirectly because where they're watching this video, around this video

10:37 are Radex components in the Epic React website. The workshop app that people go through also uses Radex heavily. And so, yeah, I'm really grateful for what you've done. So yeah, let's hear a little bit of the story of where Radex came to be. Yeah, sure.

10:57 So it started at a company called Modules. And they were originally trying to build a design tool for building design systems. So you could go in there, say you want a button, and you could style the button in the tool,

11:16 give it colors and variants and all of this stuff, and you could export it directly to code. This is like popping up all over the place now, obviously. Quite a lot of people are trying to do it. But back then, at least when I joined the company, it didn't seem to be a focus in the industry.

11:35 And as part of that, they needed these low-level primitive components that were unstyled so that the design tool could render them, and then the design tool was used to apply the styles and the props and all of that stuff.

11:52 So the API for Radex was very different when I joined. It was kind of like a component with a style prop, but not a style prop like we know it, like not the style app. It was a style prop that could take a huge nested object of styles that you wanted to apply.

12:12 And it would reroute them inside to the different parts. So it was kind of prop drilling, essentially. It would prop drill them to the different parts of the component. If you had an accordion, for example, you'd have a big object that was like accordion root, accordion item.

12:31 All the parts were in that big object with their individual styles. And then it would prop drill those styles to the relevant parts. But yeah, when I joined, there was a lot of discussion around, especially when Chance joined as well. He used to work on the Reach UI library.

12:50 We all spoke a lot about this idea of composable parts, like having a root component and an item component that's inside the root component rather than a big object. And yeah, it just ballooned from there.

13:08 We really tried to mimic what the platform does, basically. If you look at a table, you don't have a table that accepts a huge object as a prop to style your TRs and your TDs and things like that. You actually have the TRs and TDs that you can target directly.

13:26 So we just went down that road of trying to mimic the platform, but in React component form, essentially, all the way down to event prevent default, the way that instead of the platform doesn't have a load of props that say enable this, disable that,

13:46 et cetera, et cetera, et cetera, that there are attributes. They have events that you can prevent if you want to disable things. So even down to that detail, we tried to allow events to be preventable, which made it really accidentally composable.

14:05 If people needed something extra that Radix doesn't support, we can say, oh, prevent our event, and you can tweak it to do this. And they can get quite far without us having to change any of the code in Radix. It might not be the nicest or the prettiest, but it was really handy because it

14:22 allowed us to gauge these are the things that people are struggling with the most and having to prevent the most. And perhaps that should now become a feature in Radix itself. But the extensibility of it was kind of accidental. But. Yeah. Yeah. Yeah. You know, it's so important, though,

14:39 because the alternative is just every use case imaginable gets built into the library, and then the library becomes bloated, big for users to download, very difficult for maintainers to maintain, lots and lots more documentation you have to worry about.

14:58 And so, yeah, you kind of invert control. You give people the control over what order they render things in. Do I want to wrap this in a div or whatever? The one thing, and this compound components pattern

15:16 was a child of Ryan Florence. He made this pattern, and it's been really successful. Pretty much all libraries now are using this pattern. I think it's really great. The one thing that I saw in Radix for the first time,

15:34 though, I haven't seen anywhere else, is the as child prop. Where did that come from? So Benoit, I don't know if you know of Benoit, but when I joined Radix, it was mostly me and Benoit smashing out the primitives before Chance joined.

15:54 And we really struggled with the as prop. Yes, I hate that prop so much. Yeah, like I was assigned the task of polymorphic types, a polymorphic type for Radix that consumers could easily

16:13 use to build their own components with. And getting it to work, back then at least, with older versions of TypeScript, was really hard. You could get it to work, but it might be missing event types. So if you changed a button to an anchor, it wouldn't have a typed button event.

16:33 OnClick couldn't be a button event. It might be an anchor. Sorry. Yeah, if you change a button to an anchor, the event would still be a button event or not typed at all. So there were things like that. And composing multiple things together, you can't really do easily with the as prop. You can change one thing to one other thing.

16:52 But what if you want to change a dropdown menu trigger to a tooltip trigger that also attaches to your custom design system button? You have so many layers. And trying to do that with the as prop just was getting messy.

17:09 And then there's other issues, like you might pass a prop to something with an as prop. And if the component you're passing that prop to is also destructuring that prop, then it won't actually reach the component inside.

17:25 So on the surface of it, as prop looks amazing, DX, and really simple. But there's all these implicit, hidden little things that are going on with it that we were just like, oh, gosh. There must be another way. And yeah, as child was just me and Benoit

17:44 are smashing out, trying to figure out how to improve it. And it actually started as the as prop, but you passed it a slot component. So if you did as equals slot, then that component

18:03 would slot onto whatever was inside of it. We just created this slot component randomly for us to use internally. And then wider discussion started having that happening in the rest of the company about this issue. And me and Benoit were kind of like,

18:21 we've created this abstraction that could kind of maybe solve it. And then there were what felt like an eternity of debates deciding on what we should call the prop. Like, should we call it as prop? Should we call it slot? Should we call it, what should we call it?

18:37 But yeah, we eventually landed on as child, and here we are. It's great because it allows you to compose multiple things. It avoids a load of polymorphism problems because you can put your props on the actual elements themselves, on the components themselves.

18:56 It's really handy, but it also comes with its own trade-offs. So like everything, like, nothing's perfect. There's no such thing as a free app option. Yeah, yeah, yeah. That's very interesting. Yeah, building these abstract collections of components

19:14 is no joke, and making it in an accessible way is an enormous effort. And so I definitely appreciate the challenges that you faced in putting this thing together. And the team still has now, having

19:32 been acquired by WorkOS now, that they still have to make it continue to be accessible. And also with ShadCN and the popularity there, just exploding popularity in Radix recently. That's a lot of weight that the team has to shoulder.

19:51 Yeah, for sure. It's fortunately, like we spoke about, the extent that it's easy to extend and customize. So I think a lot of people are getting by without too much support, but they are lacking some components. And I keep seeing lots of requests for new ones.

20:11 So hopefully, we'll see lots of shiny new stuff at some point. But yeah, it's a great library. When you're talking about the keen eye for detail and things like that, every project I ever started before Radix, I was like, oh, drop down? How hard could it be? Like, I'll build my own, or I'll select. I'll just build my own.

20:31 When you work on components like that, and it's like, oh, hang on, what about type ahead? What about clicking outside? What about if the thing hits the edge of the browser window, there are so many little details that you just don't normally think of when you're just trying to smash something out quickly. And libraries like that are great for just getting

20:51 that stuff all out the way really quickly. Yeah, yeah, and then also making it customizable so that it can resemble your own design aesthetic. Yeah, for sure, yeah. Speaking of design aesthetic, another project that you are actively working on now

21:07 is Tokonami, which if I were to summarize it, it is CSS and JS meets Tailwind using CSS custom properties. So that's how I would describe it.

21:25 And how accurate is that? Yeah, it's pretty spot on, to be honest. Yeah, can you tell us a little bit about this project and where it came from? Yeah, sure. It actually began because React put that announcement out

21:42 that they were going to stop recommending runtime style injection. And so at the time, everyone was using like a motion or style components, or even stitches, which we also made on the module scene.

21:59 Stitches heavily relies on style injection. So when the announcement came out, I was like, oh, gosh, what are we going to do? How are we going to solve this problem? And obviously, loads of things started popping up. We had like vanilla extract and things like that coming out.

22:19 And they were all really, really great libraries, and they solved the problems really well. Basically, instead of injecting the styles, you can integrate into your bundler, and it will statically extract all the styles from your files into CSS files.

22:39 And that's great. It works really well. Except whenever I went to one of these libraries to use them in my own projects, I was so daunted and intimidated by the docs. I was like, the bundler integration immediately scares me, because I'm like, oh, gosh, I have to fiddle around in Webpack configs and stuff.

22:58 I'm not a fan. Well, and whenever you do that, too, you're very much tying your future to this bundler and that integration. Yeah, 100%. And then what comes with that is this static extraction side has a load of build time limitations.

23:16 You can't do runtime values. So I was just like, it was niggling at me. It was really niggling at me. I was like, is there not a better way? I mean, not necessarily better, but something less scary.

23:34 Something easy to set up that doesn't require bundler integration and all that stuff. And I actually, weirdly, started to try and build something like React's now implementation of the new stylesheet

23:51 stuff in the Canary release with the link tags in your body, like in your components. Because it dawned on me that link tags with rel stylesheet attributes are what's called body OK.

24:09 So they don't actually need to be in your head. Like, you can render a link in your body tag and leave it there, and it's totally valid HTML. It doesn't need to be hoisted. And so I started trying to build something that you could put a link tag in or a style tag, whatever,

24:28 right next to your component JSX inside your component JSX. And what it would try to do is, if that component rendered again, it would recognize that it's already been rendered before, and it wouldn't render the link tag. So you would only ever get the link tag rendered once. But I started doing that. It opened up a can of worms.

24:50 It doesn't work with server rendering, obviously, because it needed a lot of dynamic stuff to get the deduping to work. And then I noticed that React were already working on something like that. So I was like, OK, they've probably got a better handle on that than I have.

25:10 But still, this problem was interesting to me. And I was like, oh, is there another way that we can tackle this space that's not reliant on a particular framework? And although the React team have given us a way to style stuff,

25:26 it still has some quirks from a DX perspective. It has this president's prop. So if you're adding styles to your components, you have to give it a president's prop, which tells it what order it should be when it's hoisted.

25:42 So you need to tell it what order the stylesheets should be in, essentially, to avoid- Cascade and, yeah. Yeah, to avoid specificity issues and things like that. Which is great if you're just rendering a couple of components, and it's not too complicated to manage. But you then get into this new territory

26:02 of what's called composition across component boundaries, I think is what the StyleX team have started calling it. What if you have a button somewhere on your page, and someone's overridden that with link styles? But then somewhere else on your page, you have a link, and someone's overridden that

26:19 with button styles, like the opposite, right? So you can't just put the button style sheet after the link style sheet, because one of those buttons, one of those components is going to break. The styles are in the wrong order for one of them. So overriding, like if you have a component

26:38 and you pass some new styles to it, that override should always really, the expectation is that it would always overrule. So you kind of need the runtime for that. You don't know what order components are going to render in and what their overrides are going to be unless you're running it.

26:58 So yeah, that was a problem that I was like, ah, okay, no one's really sort of tackled this other than StyleX, of course, but again, that's heavily integrated into your bundler and stuff like that. So I was like, okay, I'm going to try and tackle this problem, how can I do it? And I looked at Tailwind.

27:19 Honestly, Tailwind is great because you don't have bundler integration. You don't have, on the most part, like this whole issue where people worry about their styles ballooning in size because it's atomic. So, you know, your styles are capped,

27:40 relatively capped on how large they can grow. You solve most of the specificity issues with Atomic CSS apart from this across component boundaries thing. And then they have that Tailwind merge library that's a third party library which solves the component boundary thing.

28:03 I was just like, they're most of the way there, like with the perfect DX that I want. My main issue with Tailwind when I tried to use it was I had to learn all these new custom class names. And I found that barrier to entry a bit intimidating in itself. If I use a class name from my theme and then delete that value in my theme,

28:27 there was no type safety. So, yeah, there were a couple of little niggles like that where I was like, okay, we have CSS variables. Do we really need a class for every property value pair when we have CSS variables? If you use CSS variables, you can apply them at runtime.

28:52 So, it solves the runtime issues. If you use CSS variables, you can solve a lot of the component boundary stuff as well, quite easily. So, I just started exploring CSS variables.

29:13 And it's, when you look at the API for Token Army, it is, it looks crazy. I've got, it looks like I've gone mad. But, you know, I started doing it just as a little side project for a bit of fun. And it's actually really cool what you can achieve with it.

29:31 So, you don't have a property, you don't have a style for every property value pair. You just have, like, you know, in Tailwind, it's like padding, class padding one is padding one. Class padding two is padding two. Class padding three is padding three. In Token Army, you just have padding equals var padding. That's it.

29:51 So, you've reduced the size of your style sheet instantly. So, I just started realizing all these cool little things that you get for it that I'd never even, never even considered when I started doing it. I just did it as a bit of fun. But, yeah, it's great. It's got a little tiny JS utility

30:11 that does the merging across component boundaries. And in comparison to Tailwind Merge, Token Army's utility is like two kilobytes when I finished doing the theme for it, whereas Tailwind Merge is like seven. And it's quite fast as well, because you're just dealing with objects and not having to parse strings and stuff, yeah. Exactly.

30:33 Like, I'm, the benefit of the CSS variable syntax is I'm literally just injecting what you write into the code. Like, I don't have to change anything. So, there's very little runtime stuff that needs to happen, apart from the merging across component boundaries where it needs to make sure the right overrides are happening.

30:52 Other than that, it's tiny. It does very little at runtime. And it server renders too. And it server renders, yeah. It server renders. There's no bundler integration. It has a little JIT compiler like Tailwind, so that as you're writing your styles, it's a style sheet being generated in the background. It's type safe.

31:12 So, you can create- That is huge. Yeah. You can create a theme like you can in Tailwind with restricted values and colors and things like that. And, yeah, you get TypeScript suggestions for everything, and you can run it during CI.

31:31 So, if you remove something from your theme, your CI build can fail and tell you that you're referencing a value that doesn't exist anymore. Yeah, so, it's come with a lot of challenges. The type safety has been hard because I'm really leaning into template literal types

31:51 for CSS variables. I think there's a cap on like a million template literal values you can have in a union. Oh, that's interesting that you would even know that. Yeah. So, yeah, when you think of all the different combinations of like properties and selectors,

32:11 like the style attribute doesn't support hover states and pseudo elements and media queries and stuff like that. So, the variables have to support that. So, you can say like hover padding is a CSS variable, but that's a template literal string that's typed. And the more selectors you have,

32:33 the more template literals you have, it just starts to like explode a little bit. So, it's been a really fun challenge trying to like keep the performance tight and still maintain the DX that I'm really after. So, yeah, it's been fun.

32:51 I think midway through building this, I don't know if you know Travis Arnold. Yeah, I love Travis. Yeah, he created a restyle library, restyle.dev, which basically gives you the same API

33:09 as like style components or emotion or whatever, but it's using the new React shininess with the precedence prop and all of that. And so, yeah, halfway through building Token Army, he came out with that and I was like, oh, this is amazing. I was like, oh, have I wasted my time? But I think there's always room

33:28 for these different solutions. And he's got the same issues as me in terms of like trying to get things to work across component boundaries. And at the time I spoke to him, I don't think he'd solved that. I don't know if he has since. But yeah, it's like if you get the nice API, it comes with trade-offs.

33:46 So Token Army has a bit of, the API might look a little bit funny, but the DX for getting started and the problems it solves and how small it is, is really what interests me. And plus it's a bit of fun. I like tinkering with it. I love it, yeah, I love it. I played around with it with the Epic stack

34:08 and yeah, basically no setup really other than just having the script running in the background and stuff. I thought it was really awesome. The funny API, I think is, what's cool about it is that the funny API,

34:27 you learn after just a little bit of time using it. And then from there, you're done learning that. Now it's just like productivity. Whereas I think with Tailwind, there's a class for every single little thing. And so you want to do something new. Well, now I got to go figure out what is the class for that.

34:43 Which is, I mean, it's fine for what you get out of Tailwind, but it would be nice to not have that. And then again, like you said, the type safety is definitely an issue. Yeah, the whole learning the class name things was exactly like being able to just say to people,

35:02 use the same CSS properties you already know and just prefix them with a double dash. Just turn it into a CSS variable. Then you've learned Token Army, that's it. You don't need to keep checking the docs to see how to apply padding or how to apply margin or what name they've given to align items. So yeah, it does reduce the barriers of entry.

35:24 And you thankfully, when you tried it, did mention the theme issue, how there was no default theme out of the box. And you felt like you were doing arbitrary values all the time. And I have to thank you a lot for that because creating a theme was kind of like really low on my priority list. I was like, ah, I can get through without one of them for now. But since you've said that,

35:45 I've been focusing a lot of my spare time on building kind of like a Tailwind equivalent so that out of the box, people have a design system with lots of tokens, ready-made and colors that they can use. So yeah, like hopefully next time you try it, it'll feel a lot simpler and a lot easier to get going with. That sounds great.

36:04 As somebody who uses CSS to just make it look good and now I can move on to the stuff I want to do. Yeah, it's definitely appreciated. So I love it. And I do want to know, what do you think is the thing that's stopping you or is there anything stopping you

36:27 from just saying everybody should be using this? Like why should somebody not use Tokonami? I think right now, as soon as you go to the website, it's like this is pre-alpha. So it's like scaring everybody off. And the reason it is so pre-alpha is I have these features in my mind

36:48 that are gonna be pretty huge breaking changes. So once I've delivered those, I would be more for like saying to everyone, yeah, use this in your production app. But right now it is still, I'm smashing out code and I'm just trying to get it working

37:06 and proving my idea and still so many like little features I wanna do. Like for example, I noticed a lot when I was building applications that in Tailwind specifically, there's this whole debate around repeating classes in your markup. And it's like, oh, it makes your HTML massive

37:28 because you've got the same classes repeating over and over and over and over again. And the guys, the Tailwind folks are like, well, it's not really an issue, create a component. And then you just reuse that component and you don't have to repeat the classes all the time. But the classes are still being repeated in your markup. Like that issue hasn't gone away.

37:47 You do still have a huge HTML file size. So there's a problem there that I really wanna solve with Token Army. Like because Token Army works a lot like Tailwind, everything's in line. It does have that same issue. It really bloats your HTML.

38:07 So a big feature I wanna work on is, I essentially have two APIs in Token Army. One's like an API you use for prototyping in line quickly. And another one is an API you use for when you're creating components, which has all the variants, API stuff that you see from stitches.

38:28 And I realized that usually when people want variants and things, they're building a component. And usually when you're building a component, you don't want those styles repeated in your markup. You want them in your style sheet. So because I have the two APIs, it makes it easier for me to know which styles should stay in line

38:48 and which styles I can pull out into your style sheet. Very interesting. Yeah. So this is a feature I'm planning to deliver at some point so that you can heavily cache your style sheet. And if you're changing your markup or whatever,

39:08 you're not busting your CSS for your components and vice versa, right? You can heavily cache things. So yeah, that's a real big feature on my list that I wanna tick off. But because there's no bundler integration, it's a really tough one to solve. Yeah. Yeah, how do you know?

39:30 Well, yeah. That's interesting. The size of the markup, I have been less concerned about because that can be gzipped and everything. But still, it would be a cool one to have solved. Yeah, I mean, same. I've never really cared about the markup size.

39:48 It's more like the caching side, the caching feature. I'd like to be able to change a component without busting my whole page, my HTML page. So let's say if I had a huge document, I've cached quite heavily, static, it rarely, like a blog post, never changes, heavily cached it.

40:08 But now I go and change a button on another page on my website. That's just now invalidated the cache on my blog post, right? I'd like to be able to change the button on my about page without invalidating the cache on my blog post somehow. And this would solve that if we could abstract component styles into the style sheet, you would be able to keep things cached essentially.

40:31 Yeah. Yeah. You got to noodle on that one a little bit more. Yeah. Cool. Jenna, this has been so fun to chat with you about RADIX and about Tokonami and also even AI and everything. Is there anything that you were hoping we could talk about that we didn't get to chat about? No, not really.

40:54 I think we've covered all sorts of exciting stuff. I mean, if people haven't checked out the React Canary style sheet stuff, go have a look at that. But yeah, we've covered loads of bases. Nothing else to add. Awesome. Great. What's the best place for people to keep up with what you're up to? Probably Twitter.

41:15 I'm always on Twitter. I'm like embarrassingly addicted to it. Oh, well, I am also. Thank you. J-J-E-N-Z-Z, right? Yes. Yeah. Cool. Well, thank you so much, Jenna. It's so great to chat with you again and hopefully I can make it back out there to London

41:36 to come and see you again. Yeah, that would be lovely. We'd love to see you soon. Thanks, everybody. Thank you. See you later. Bye-bye. Bye-bye.