Pod Insights Software Engineering Daily Radix UI with Chance Strickland About this episode Radix UI is an open-source library of React components. Its “headless” primitives handle the complex logic and accessibility concerns—like dialogs, dropdowns, and tabs—while leaving styling completely up to the developer. The project emphasizes usability, accessibility, and composability and has become a vital part of modern web dev, in part because it forms the foundation of shad/cn UI.
Chance Strickland https://x.com/chancethedev is a software engineer at WorkOS https://workos.com/ and a maintainer of Radix UI. Chase joins the show with Nick Nisi to talk about Radix, its primitives, Radix’s relationship with shad/cn UI, the evolution of web primitives, and much more.
https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2025/05/Nick-Nisi.pngNick Nisi is a conference organizer, speaker, and developer focused on tools across the web ecosystem. He has organized and emceed several conferences and has led NebraskaJS for more than a decade. Nick currently works as a developer experience engineer at WorkOS.
Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2025/11/SED1871-Radix-UI.txt
Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected]
The post Radix UI with Chance Strickland https://softwareengineeringdaily.com/podcasts/radix-ui-with-chance-strickland/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.
Transcript 11,104 words · 3 speakers
0:00 Speaker 00 Radix UI is an open source library of React components. Its headless primitives handle the complex logic and accessibility concerns like dialogues, dropdowns, and tabs while leaving styling completely up to the developer. The project emphasizes usability, accessibility, and composability, and has become a vital part of modern web dev, in part because it forms the foundation of Shad CN UI. Chase Strickland is a software engineer at WorkOS and a maintainer of Radix UI. Chase joins the show with Nick Neese to talk about Radix, its primitives, Radix's relationship with Shad CN UI, the evolution of web primitives, and much more.
0:42 Speaker 00 Nick Neese is a conference organizer, speaker, and developer focused on tools across the web ecosystem. He has organized and emceed several conferences and has led Nebraska JS for more than a decade. Nick currently works as a developer experience engineer at WorkOS.
1:12 Speaker 01 Hello and welcome to Software Engineering Daily. I'm your host, Nick Neese, and I'm joined today by Chance Strickland. Chance, how's it going?
1:21 Speaker 02 Good. How are you, Nick?
1:22 Speaker 01 I'm doing fantastic. I'm ready to talk about Radix, Radix, however we want to pronounce it, but it's a very exciting project. But before we do, why don't you tell us a little bit about yourself?
1:32 Speaker 02 Yeah, my name's Chance Strickland. I live in San Diego, California. I am a software engineer at WorkOS. And yeah, working on all of our front-end things and still maintaining Radix as well. So that's kind of like my split of the day job. And then outside of that, I have a dog and live with my wife in North Park, San Diego, like I said, and like to play music. That's a pretty good holistic script, I think.
1:58 Speaker 01 Yeah. What instruments do you play?
2:00 Speaker 02 I've got some drums behind me. So yeah, I don't know. Is this going to be a visual podcast? Can anyone see this? Or is it just audio? If it's just audio, I will make sure I don't make any more visual references. But yeah, I play drums. I've also got several guitars back here. So yeah, I dabble in a few things.
2:15 Speaker 01 Awesome. Nice.
2:17 Speaker 01 Cool. Well, why don't you tell us what Radix is or Radix and how you pronounce it?
2:21 Speaker 02 I guess first we can start by pronunciation because I've always said Radix, but I hear people all the time will come up and say, hey, I love Radix UI. And I'm like, that's cool. And I don't say anything because I don't actually know if I'm right. The project was started by a team of half Americans and half Brits. So like between the accent and potential pronunciation differences between the two, I don't know. Actually, I just have always said Radix.
2:45 Speaker 01 Cool. Yeah, it's kind of got that Vit Vit vibe there.
2:49 Speaker 02 Exactly. You can call it whatever you want. That's totally fine. It'd be more fun if we said it differently the entire time.
2:55 Speaker 01 I will probably do that, but without even trying. You keep telling me and then I immediately just goes through my head.
3:03 Speaker 01 But that's okay.
3:03 Speaker 02 Totally fine. Yeah.
3:04 Speaker 01 It's a really cool project. Do you want to describe what it is?
3:07 Speaker 02 Sure. Well, it's actually a few different things. So Radix is kind of like this umbrella of a few different projects. The one that most people know about and think about, I think when they think of Radix is the primitives. Radix primitives is a group of composition first compound components that has been used for quite some time, sort of encapsulate different patterns, common patterns you see on the web that are generally somewhat complicated to implement yourself and customize. Some of them build on top of web primitives and some of them predate some existing web primitives in some ways. And we could talk a little bit more about that. But essentially it's a component library for building on the web.
3:50 Speaker 02 So if you need things like a dialog, if you need, you know, a tabs interface, if you need an advanced customizable select dropdown or some other type of dropdown menu, like we have all of those components ready to go out of the box. We tried to build them in a way that is as accessible as possible so that you don't have to think a ton about accessibility and also just general usability. We put a lot of work and effort into making the experience very seamless when using Radix components. And we also make sure that they are style agnostic. So that's kind of it in a nutshell. And then, like I said, we have a few other projects as well under the Radix umbrella. have Radix Themes, which is also a suite of components, but it sits at sort of a higher level in abstraction.
4:32 Speaker 02 So it is completely styled by default and has a themable API. So that you can get up and running with your app a lot more quickly without even thinking about styling. And then you can customize it through the themes interface. And then we also have a Radix Colors, which is a very meticulously designed color system for very seamless switching between dark and light mode in a way that is aesthetically pleasing, but also designed again from an accessibility first approach. So you don't have to think as much about things like color contrast ratios. And then we also have Radix Icons, which is a suite of icons, as you might imagine. So those are all the projects under the Radix umbrella.
5:15 Speaker 02 But yeah, most people I think are going to associate us with Radix primitives.
5:19 Speaker 01 Yeah, I think so. And that's probably how I have come to know Radix as the primitives themselves. But I want to talk about each of these pieces, but let's just start with the primitives there. Is another way to classify them, I guess, would it be safe to call them headless?
5:35 Speaker 02 Sure. Yeah, I like that term.
5:36 Speaker 01 Cool. And the way that I came to that term or came around to liking that term was because on a project I was working on, we were using Material UI and everything kind of looked materially. And we wanted to get away from that and kind of have our own stamp on the design. And Radix primitives seemed like a really good way to go with that because they really didn't give us any kind of style by default, just with the primitives, so that we could apply our own. But we weren't missing out on all of the benefits of not developing these components ourselves. And that's in my mind, like all of the accessibility features and browser compatibility.
6:15 Speaker 02 Yeah, no, that's absolutely correct. We want to give you maximum flexibility in terms of the presentation of the components, but the underlying patterns should behave similarly across the board, across different browsers, different assistive technologies and how they interface with these things. Those experiences need to be somewhat consistent, but the look and feel is obviously going to be determined in large part by your brand.
6:35 Speaker 01 Now, it just naturally makes sense to have those primitives and then also to have like a set of designs on top of them or themes on top of them, which gets into the themes part of that. And you said that they're styled by default. So this would give you like a kind of a natural Radix look and feel if you use those. But then they have a themable API. So how customizable is it from there?
6:56 Speaker 02 Yeah, it's pretty robust. You can actually do quite a bit with it. If you go to radix-uI.com, you will be greeted by the Radix Themes splash page. And there are actually live examples that you will see. It's like a carousel interface where you can reset the theme of the homepage itself, which is kind of neat, but it just sort of showcases some of the flexibility of Radix Themes. Now, that being said, it is opinionated, right? Like any freestyle library is going to be opinionated. You've mentioned Material UI, very opinionated. It tries to strike somewhat of a balance because you do want ultimately to decide some aspects of look and feel. But if you are just trying to bootstrap a project and get it off the ground and don't want to think too much about the styles, Radix Themes is going to look really
7:37 Speaker 02 nice out of the gate. Then later you can come in and change fonts if you want, come in and change your primary colors. It uses Radix colors under the hood. So you can set a single primary color and get an entire range of colors generated from that, which is quite nice. And again, it just sort of takes away some of the mental overhead of thinking about things like color contrast. And of course, it's built on Radix primitives. So again, accessibility is sort of top of mind there, usability is top of mind. So all of these pieces play into Radix Themes and as like our higher level tool for building apps on the web.
8:10 Speaker 01 Very cool. I love that, that you can just start with a color and go. Most of the time, that's like what you want, at least to get started is like, I want the brand color and mix and match from there, but also have good contrast between text and background and things like that. And so really nice. You can start at any level and get going and then kind of customize to your heart's content.
8:30 Speaker 02 Yeah, absolutely.
8:31 Speaker 01 So I'm just curious, you've got the themes, which naturally out of the themes would come the colors, right? And icons. How are those picked? Like, what goes into doing this? Because honestly, this is like something that I can't comprehend. Like picking the right color and then a complementary color.
8:48 Speaker 02 That's a great question. And honestly, it's something I don't really comprehend. So just to be completely clear, I didn't build either of these libraries.
8:54 Speaker 01 Sure.
8:54 Speaker 02 I maintain mostly primitives and I do like still maintain these libraries, but the underlying libraries or the beginnings, the origins were not me. And I don't have the meticulous, obsessive compulsive tendencies to like design an icon suite that is like, the way that these things are optimized is actually pretty incredible. And most people don't think of icons as this like really complex thing. But if you want your app to look really consistent across the board, things like line weight and base sizing, and how each icon scales up to different screen sizes and how different icons appear in relation to one another. All of that matters a lot more than people realize. Like your average person looking at a web app doesn't notice that the icons are slightly different,
9:37 Speaker 02 but they notice something is off, right? Like they can't pinpoint it, but they know when something looks good and they know when something doesn't look good. And to make the thing look really cohesive and really good, you obviously need a lot of cohesion between the small little details and small elements. And so the icon suite is meticulously designed just for that. It was originally designed by, he no longer works for WorkOS, as things call him, but and I apologize, Colm, if you're listening, I don't remember his last name. I'm gonna have to look it up because I do want to plug him. Starts with a T. But anyway, he and a guy named Vlad on our team, I think, co-designed those. And yeah, like I said, really, really well done. I don't have to really touch them too much anymore, but we do have a couple of new icons in the works internally at WorkOS.
10:20 Speaker 02 So anyway, rambled enough about icons. Color system is kind of the same thing. Like I didn't build that myself either. And again, I probably could if I wanted to sit down and spend that much time on colors, but that's just not what I'm interested in. But it is pretty incredible. Actually, it's a lot harder than people realize. And that's kind of a theme with Radix. Like everything that we do presents as fairly simple, but then once you peel back the onion a little bit, there's a reason people don't want to do it themselves. It's actually very hard, a lot harder, a lot more time consuming than people really need to be investing in most cases. When what you really need to be doing is spending time on your Product. And so you want tools that help you spend time on your product and not waste time thinking about color scales. And that's really what it comes down to. So yeah, I try and
11:05 Speaker 02 maintain it as best I can. We have some ideas on how to improve both of these libraries moving forward, but the core underlying piece of it, which are the icons and colors themselves are mostly sort of bakes.
11:16 Speaker 01 Very cool. And yeah, that's a great point about you can just go down so many rabbit holes on any one of these components and spend so much time there. And that's not actually contributing to the overall product that you might be designing. So it's great that these exist for that and give you like full customizability in terms of styling and how it looks and how it feels. I do, I have so many questions about the primitives themselves. I guess first, let's talk about what they're made in. Are they React components?
11:43 Speaker 02 Yep. Everything is built around React. So if you use React, awesome. If you don't, I'm sorry, we don't have anything for you. But yeah, they're all React components. We had discussed in the past, like sort of expanding this and maybe taking like a web components first approach and then making those extendable so that you could pull them into a framework of your choice. But ultimately, React is where most of the users are. And it is just sort of like, we want to meet the users where they are. And that's our approach. And of course, at WorkOS, we use React internally, extensively throughout our stack. So yeah, it makes a lot of sense for us to stick with React.
12:17 Speaker 01 Very cool. Yeah, React is definitely where people are at. When it comes to styling, whether it's directly on the primitives or through like the themable API within the themes, are they like the same in terms of how you would do that? And does that support like any styles that you might want to use or any styling frameworks?
12:37 Speaker 02 So like I said, themes is opinionated. It's also customizable to the themes interface. But my favorite thing about React's themes actually is the fact that under the hood, everything that powers React's themes is just CSS. So there's no special runtime JavaScript or anything at play to prevent you from styling anything in your app outside of the themed interface. So at the end of it, what you do with React's themes is you essentially import a few style sheets. And then once you do that, you have all of the class names mapped to the components you get from React's themes. But at the end of the day, it's all just CSS. So overriding Radix Themes or even selectively including certain style sheets. We have like different levels of abstraction for our style sheets. So you can only import things that you want from our layout components like
13:22 Speaker 02 grid, flex components, like we have different layout specific components. If you only wanted those, you can only import that and start building your own color system on top of it. If you want the whole kitchen sink, you import all the style sheets, but then you can go and you can target overrides. You can reset certain variables that we might set under the hood. Like it's extremely flexible in that way, because if you write CSS, you just write more CSS. And because of the cascading nature of CSS, it's not terribly difficult to override things. But we obviously don't necessarily think you should have to be overriding too many things because that's kind of the point of an opinionated library. But it is flexible in that way. And I think those the CSS only approaches is giving you a very simple escape hatch.
14:03 Speaker 01 What if you're afraid of the cascade like me and you just use Tailwind?
14:06 Speaker 02 You know what? That's fine. I don't have anything. How many people do you want to upset in this podcast is the question, I think. I don't know why the Tailwind thing is so polarizing, but use what makes you happy. I will say like Tailwind is at odds with Radix Themes, but they are two different paradigms for solving similar problems in some ways. Or really, I guess how I would describe it is Radix Themes is half primitives and half something like Tailwind, right? Like half of it are the components themselves, which obviously Tailwind doesn't provide. The other half is styling, which Tailwind does provide, and they have two very different approaches to styling. And so I would say if you are using something like Tailwind already and you're using it extensively through your app, may not be the best fit to then go
14:49 Speaker 02 and grab Radix Themes. But what's great about Radix again is we have other levels of abstraction and you can go grab Radix primitives and then you can slap whatever Tailwind classes you want on any element you want. And at that point, it's just Tailwind's styling and have a blast with it. We don't really care. So I don't really care. Some people care. A lot of people care. I don't know. It's like, it's one of the most polarizing topics. I feel like anytime it gets brought up, which I find odd. As a someone who loves CSS and thinks Tailwind is a great tool, I don't really understand the polarization, but.
15:21 Speaker 01 I agree.
15:22 Speaker 02 Use what you want.
15:23 Speaker 01 Yeah, I feel like Tailwind taught me a lot about CSS instead of taking away from it. So that's good overall. I wanted to circle back to something that you mentioned, which was some of these components predating some web primitives. Can you give an example of one?
15:37 Speaker 02 Oh, sure. So dialogue is a great example where we now have a dialogue element. That's just a raw CSS element. The Radix primitive, when we first started Radix, I believe dialogue was technically a thing, but it wasn't super customizable. And I'm pretty sure at the time it was fairly buggy or incomplete implementation in probably Safari. I don't remember exactly, but it was technically there in some capacity, but it was not robust enough for you to really realistically be able to use it in a complex web app. And that's also kind of a common theme is that there are cases where certain elements that exist on the web are usable and functional in sort of simple cases.
16:20 Speaker 02 But as the complexity grows and the needs expand, then you might need to reach for something a little bit more customized. And so dialogue is one example of that. Obviously, HTML has a select element that's been around for ages, but we all have tried to customize those and we understand how painful it can be. That is actually changing, by the way. There are new elements that have been introduced in HTML specifically for customizing the select. And that is also really exciting. I can't remember offhand what those APIs are, so I'm going to check that out. But yeah, it's pretty cool what the web can do for you these days that in the past you would have needed a ton of JavaScript to replicate that behavior. So those are two examples and.
17:04 Speaker 02 Oh yeah, collapsible is another great one. Collapsible just essentially being an element that triggers a collapsible section and toggles it on and off. We now have details and summary elements in HTML, so you rarely need to reach for JavaScript for that. So these things are all still really useful and robust, but yeah, the web's come a long way in the last several years.
17:25 Speaker 01 Yeah, for sure. Do you anticipate like, I guess, when that happens, when the web catches up to something that's existed in in Radix for a while, I imagine that it might lead to like, I mean, you don't have to adopt it, I guess, is the answer. But like, if you wanted to adopt it, would it lead to like breaking changes? Or do you just kind of keep your own separate implementation of that? How do you approach it?
17:48 Speaker 02 Yeah, so it totally depends. That's the answer to every question, right?
17:51 Speaker 01 Yeah.
17:51 Speaker 02 It depends. But it really does. Like, it depends on a few things. So one thing that I always look for in these new web primitives is how flexible and robust are these primitives? Like, in some cases, they may be completely adequate for building the most complex web app that you can imagine. Now, we build React components. React generally is something you would want to reach for in a more complex web application context. A little bit more rarely, I'd say, do you want to reach for it for something like a marketing splash page or a blog? Things that are totally fine to build with web primitives and don't require a lot of advanced use cases, I would say just go with web primitives and save yourself a lot of pain and JavaScript.
18:34 Speaker 02 In more advanced applications, like the one that we work on at WorkOS, they're just not always robust enough to handle those cases. And the web is improving on that front, but I still need to check out, like, can these web primitives do everything that Radix can do today? If the answer is yes, maybe we could either phase out the component altogether and recommend people use web primitives, or we could build our primitives on top of the web and pull out a lot of our own custom JavaScript that we need to write to maintain really complex logic. So it really just depends on what the element is that we're talking about. What are these new web primitives actually capable of? And how much value can we still provide you with Radix?
19:16 Speaker 01 I want to shift gears a little bit and talk about you and your journey into maintaining Radix. Can you give us that story?
19:24 Speaker 02 Yeah, so before Radix, there was another React library that was actually fairly similar in its goals and design, and it was called ReechUI. And one of my very early projects, I was a full-time freelancer for several years and I was working on various apps of different sizes and scales and at some point caught wind of this really cool new thing called React that everyone was talking about. Didn't really know much about it. I was just slinging jQuery and CoffeeScript at the time. Doing my best with what we had, but there was this really new, interesting library that everyone was talking about and I decided to check it out one day and I've not really looked back. So I've been knee-deep into the React
20:06 Speaker 02 ecosystem ever since and I don't even remember what year that was, but it was pretty early in React days. So I kind of just sank my whole career into that. And as a result, you're building these applications. For me as a freelancer, I was building all kinds of things. Like I wasn't working on one singular product. I was just sort of helping different teams or helping launch products, whatever the case may be. And so there's a lot of different things that I'm working on week after week. So I inevitably need to find a lot of different tools to help me do that job efficiently and over time React became more widely adopted. I started to see a lot of third-party tools and libraries pop up around React.
20:43 Speaker 02 That's made my job a lot easier. So as time goes on and I'm looking through all of the different tools available to me, I stumble into this library called ReechUI. And it was super helpful. It provided a lot of similar components that you'll see in React today. Things like dialogs, tabs, menu button dropdowns, that sort of thing. And just little pieces I could grab and stick into my code and then make them look however I wanted to and just build my product a lot faster. And that was exactly what I was looking for. What was also really cool about ReechUI was its composition model. And this is something that really it's sort of the core behind why React took off in the first place. It's just the underlying composition model of React itself.
21:25 Speaker 02 And ReechUI really leaned into that composition model and it gave you different pieces of React components rather than trying to stuff everything into a single supercharged component, like a library some people might be familiar with from back in the day and may still be maintained. I don't know. It was called Downshift. This is a really popular library. That you would grab and it would give you the ability to style a complex dropdown select component, right? But it was very powerful, but the API itself was kind of clunky to work with because a custom dropdown ultimately requires that you have a lot of different elements on the screen, right? You're gonna have the trigger, you're gonna have the list itself, the pop over, the list is inside of, the items. And it just sort of gave you this big fat component with a bunch of render props that
22:10 Speaker 02 allowed you to sort of customize things, but it was just really clunky to use. And ReechUI addressed that kind of thing by giving this composition first API where the root of the component might provide some context to underlying components and underlying components are directly mapped to one or two different elements, but everything is sort of low level and composed by passing children to your other components, which that's just how React was modeled in the first place. And so it made a lot of sense to me and it also really impacted on how I built components in my own apps. So the things that ReechUI didn't provide to me, I needed to build myself. But as I was building them, I would think to myself, how would I build this if I were building ReechUI?
22:55 Speaker 02 Because that design just made a lot of sense and it made things really easy to maintain. And so the first component that I remember building that way was an accordion. Reach at the time didn't have one. And I needed an accordion for a project and so I sort of just built it the way that I would imagined Ryan Florence would have built it into Reach. And I just happened to be at a conference some years ago that I popped into React Rally. And at the time, it was still being maintained by Ryan Florence and his business partner, Michael Jackson. And I was chatting with Michael just casually, not looking for a job at all. I was perfectly happy as a freelancer, but we were talking about Reach and I was like, oh yeah, like I use Reach and it's great. I love it. And I even build like some of my own like Reach-like
23:38 Speaker 02 components sometimes. And I've got my own like little mini Reach extension library that I've been working on. And he was like, oh, let's look at it. Let's see it. I want to see what you're building here. So I pulled it up. I showed him my little accordion component and how it was modeled. And he said, well, How would you like to work on these things full time? And so, well, that sounds awesome. Why would you want me to do that? It'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.
24:23 Speaker 02 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. And 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 that 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 then builders of the Radix project. And then fast forward to whenever it was that WorkOS acquired the Radix team, I actually like went off and worked for a different company,
25:08 Speaker 02 helped build Remix and 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.
25:25 Speaker 01 Very cool. Since you mentioned it, I'm looking at Reach UI 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.
25:38 Speaker 02 Oh yeah. So that's a funny one too, because component component, well, A, 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 is 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 in child. Components before the hooks world, right? So prior to hooks, there were a couple of 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? Like we all just pass props along.
26:23 Speaker 02 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 you 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. And so there were different patterns adopted for this with 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.
27:06 Speaker 02 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 and became pretty tricky. So this was all pre-context. So React context changed a lot of this, but also React hooks obviously changed a lot of this where you could use the context directly without having to, again, prop drill. But before all that, Ryan decided he was going to try and solve this problem in third-party land and he came up with Bonnet 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 hooks came out and solved a lot of these problems for us.
27:52 Speaker 01 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. But 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, 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.
28:37 Speaker 01 I'm not trying to like make you say anything controversial or anything. I'm just curious if you had any thoughts on that.
28:42 Speaker 02 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 lose the hell, something along those lines. Anyway, so I try to keep an open mind in 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 open, this free time. What are we going to do with it? Now's a good time to like work on this framework that we've been cooking around in our heads for the last several years. Cause remix really was a series of ideas that Michael and Ryan just had, but never took the time to to build it. And now they had the time and so they they thought, why not build it now?
29:25 Speaker 02 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 this is small scrappy little startup trying to 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. And 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.
30:03 Speaker 02 But as you might know, or listeners may or may not know, at ReactConf, 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? And 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.
30:47 Speaker 02 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. Like, the, the heart of any framework really is the router. And 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 they, 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, that React Router just looks like Remix, except for there's no server. Like, it's just a client-side library, but the actual APIs look a lot alike. And at that point, what is Remix even?
31:32 Speaker 02 Remix is essentially a compiler that allows you to build a React Router app and target a server and a client. Why 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, so how do we solve that?
32:13 Speaker 02 Well, again, I go back to the fact that they still had a lot of really cool ideas for Remix. And, 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, at the point when they decided to do this fork in the road. So I'm, I'm just making guesses alongside the best of us, you know? I, I'm, 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. That's ultimately what it was. Like the underlying selling point of remix from the very beginning was to build a JavaScript
32:57 Speaker 02 framework that really looked like the web.
33:00 Speaker 01 Mm hmm.
33:01 Speaker 02 It used web primitives under to 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 web first 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? Again, no special knowledge here. I don't know if they're going to build remix on top of web components. It 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.
33:46 Speaker 02 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 it like 10, 11 years old at this point? 12 years old, you said 2013, so yeah, like 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. And every time I've ever doubted them, they've proven me wrong.
34:31 Speaker 02 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.
34:38 Speaker 01 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.
34:56 Speaker 02 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. And so I know, I do know for a fact that they put high value on that. And whatever we see will have a very composition-driven API for building components. So I'm stoked to see what it is.
35:21 Speaker 01 Same. Yeah, I'm looking forward to it. Always good to see new innovation in this. Now, getting back to Redux, I did want to ask about something that I actually don't know a lot about. Even though I've used Redux a lot, when the topic of Redux comes up, inevitably, ShadCN comes up. Can you explain the relationship between Redux and ShadCN and kind of how that came to be?
35:44 Speaker 02 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. And 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? Like, you didn't install anything from NPM. There might be a few underlying dependencies, but it was a copy-paste-code approach, which 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.
36:29 Speaker 02 You 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 gotta, you gotta take it out of the Node modules and stick it in your, 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. They got a lot more components and then they ultimately built like a CLI tool that you could use to just drop the,
37:11 Speaker 02 so you didn't have to like manually copy paste things. You just drop 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. So 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 ShadCN dialogue, that's going to be under the hood,
37:53 Speaker 02 a Radix primitive dialogue that comes with a bunch of pre baked styles using Tailwind classes.
38:00 Speaker 01 Okay. So could you think of it as like another theme? I guess I'm trying to.
38:07 Speaker 02 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? ShadCN does 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 every, all of your ShadCN 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, with a library first approach. So yeah, it is a different approach to solving a very similar problem.
38:49 Speaker 01 Got it. Okay. And is there any like collaboration between the two teams on these two working together or like?
38:56 Speaker 02 Not at all, but if they, if anyone is working on ShadCN wants to come help us out, let us know. Been, been open to it, but yeah, waiting for that phone call still.
39:05 Speaker 01 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 like 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.
39:27 Speaker 02 That's right. And it's not just Radix. There's other dependencies in the next two for certain components. They come baked with some some icon libraries, I think. So yeah, there's a number of other libraries, but essentially shad CN 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.
39:47 Speaker 01 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?
39:59 Speaker 02 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 CN 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. And 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
40:43 Speaker 02 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.
41:01 Speaker 02 The implementation of what do people need to reach for to build for the web? And 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. But 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?
41:45 Speaker 02 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 L L M's and different A I tools, basically allowing you to drastically shortcut build times. And so like the interface for actually building things with L L M's is very different than how we've done things in the past. So 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.
42:24 Speaker 01 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?
42:34 Speaker 02 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 dog fooding. So like pretty much any tools that we build for customers, we try and also use ourselves. And 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 are around authentication.
43:15 Speaker 02 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? One example being a one-time password field, you know, we, we've all seen the one-time password field, which is essentially six mini 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 paste in all the inputs because it's, it's interesting because it's really one input. It's just visually six different inputs, but that also kind of comes with like,
43:56 Speaker 02 when you visually alter an input, maybe there's like different user expectations for how things behave than a normal input. So 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, 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, you know, four places to the right. It's, it's one input and there's only as much space as you've entered white space. So like, there's different things you have to think about when, and this is what I talked about early. 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. And 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.
44:40 Speaker 02 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 so 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. Password toggle field, another interesting one. Uh, 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.
45:25 Speaker 02 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. Cause you don't want to have to keep tabbing back and forth, right? Or 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. And as soon as you satisfy that need, it stops yelling at you.
46:07 Speaker 02 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.
46:32 Speaker 01 Combo box, I imagine is one.
46:34 Speaker 02 No, don't, don't even say the word.
46:36 Speaker 01 I thought that you had a really good explanation of as to why that might not be.
46:42 Speaker 01 It's hard. It's hard to do right.
46:43 Speaker 02 That's the answer. You know, it's been brought up a number of times. And at this point we can have, we joke about it a lot in our internal meetings, but you know, I guess I keep your eyes open. Never know.
46:54 Speaker 01 Awesome.
46:56 Speaker 01 And yeah, I just wanted to say on, you know, the auth specific components, like particularly the OTP.
47:01 Speaker 02 Yeah.
47:02 Speaker 01 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. And 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.
47:40 Speaker 02 Absolutely. So, and it's not just one password. People use other password managers.
47:45 Speaker 01 Of course.
47:45 Speaker 02 Have different mechanisms for handling this thing. And so, 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. Like 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.
48:15 Speaker 01 Mm hmm.
48:15 Speaker 02 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.
48:25 Speaker 01 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?
48:37 Speaker 02 Yeah. 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, 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.
48:53 Speaker 01 Mm hmm.
48:54 Speaker 02 But then it, that sort of constrains you a bit because now, like it has to, you can only focus at one, like it's one input. So that input's the thing that always has the focus, right?
49:04 Speaker 01 Mm hmm.
49:04 Speaker 02 And when you enter one character and you move, you know, move over to the right, you have different characters. Like 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? So 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, 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.
49:43 Speaker 01 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? You 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?
50:13 Speaker 02 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, like, work well with composition-first APIs. And so it's really easy to ask a, an LLM something, or go to ChatGPT and ask it for something, to build you a React component. And 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,
50:54 Speaker 02 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 Claude config file in your codebase that sort of helps the tooling understand Radix a little bit more in depth, understand how you've implemented it in your own codebase. These 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.
51:39 Speaker 02 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. And again, a lot of ideas that we are currently baking.
51:57 Speaker 01 Yeah.
51:57 Speaker 02 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.
52:08 Speaker 01 Yeah, no, that's great. And I think that that's enough right now. You know, we don't know where this is all gonna 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. I think that's comforting for sure. So yeah, that's a good answer. Finally, is there anything that we haven't talked about that you want people to know about Radix?
52:35 Speaker 02 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 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. But 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.
53:18 Speaker 02 Like, a lot of us just think of open source as this thing that you get for free and like, there's not like 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 like, understand a little bit more about what goes into it. And I don't know, maybe give you a little bit of empathy for the folks who are building it. I'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.
53:50 Speaker 01 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 eye opening, 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. Well, very cool. Chance, where can people find you on the internet?
54:13 Speaker 02 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, 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.
54:38 Speaker 01 Awesome. Well, thank you so much for spending time with us today and we'll catch you next time.
54:41 Speaker 02 Yeah, thanks. This is awesome.
Previous The 2025 Stack Overflow Developer Survey with Jody Bailey and Erin Yepis Next Drone Warfare in Ukraine with Simon Shuster Page updated November 6, 2026 · transcript and summary are machine-generated