Ben:
Hello and welcome to PodRocket. Today I'm here with Benoît Grélard, who is a software engineer at WorkOS. How are you Benoît?

Benoît:
I'm good, how are you?

Ben:
I'm doing well. I'm excited to learn about some of what things you've built in the past and things you're building moving forward. So you are one of the creators of Modulz, right?

Benoît:
So Modulz was a startup I was working at. I was there on Radix UIs, which is I think the products that you are referring to. It's sort of an accessible component library for React.

Ben:
Component library for React. And what was or is Modulz?

Benoît:
So Modulz was the startup that was in the design tooling space. We're basically trying to create a tool similar to Figma but working with real components. So if you think about all the complexities of layout and all these things, and the sort of developer designer handoff, all of these things were kind of at the forefront.

Ben:
Got it. So basically, kind of like a visual gooey-based editor, I guess Wizzy Wig you would call it, where you can design components visually. But unlike Figma where you're doing it more in a design tool, this would be actually editing real React components?

Benoît:
That's correct, yeah. And then you would have the opportunity to export that and then have that actually kind of usable. You can already see day-to-day in the past few years or so, Figma is kind of in a way catching up with what the web is able to do. They integrated things like flexbox layout and things like that, auto layout, all these kind of things. They're trying to fill the gap that design tools, they're just rectangles on a canvas. They're not real components with constraints and all that. So there's definitely a need there and obviously they're trying to do that and so we were attacking it from the other front, which is starting straight from web technologies, basically.

Ben:
Right. And I mean I feel like Wizzy Wig, what you see is what you get. [inaudible] not familiar with the acronym, editors have been around in many iterations as old as the web itself. I mean, back in the day.

Benoît:
Dreamweaver.

Ben:
Exactly. A lot of us kind of first got our start on Dreamweaver, but then over the years, every year or two I feel like I see a new one that kind of gains momentum maybe. But it doesn't feel like there's kind of a gold standard and no one's kind of built a company as ubiquitous as Figma that is Wizzy Wig component or web editor. So curious, what was special or what was the angle you had with Modulz that was maybe different than the prior art?

Benoît:
Yeah, that's a great question. I think partly, one reason is it's very difficult to build. It's just very difficult to get right and there's tons of little details. We tried a few different approaches. We kind of approached it more from the systematic design point of view. We had design systems in mind. We did a lot of work actually on there, which is partially, well it's a big reason why Radix UI exists, basically. Because we initially started more on a composer idea, which you know could build entire interfaces. Then we moved towards more of a design system builder where people would be able to come and just style a bunch of components and then use that as their components. Because we saw just tons of teams building their own design systems, most of them not accessible and just reinventing the wheel and that kind of stuff.

Benoît:
So we saw actually most people what they wanted, they just want to be able to make it look the way they want. So for that, we needed to have a bunch of components that were good quality and this is where it all started for Radix. Then we went back and forth. We then eventually went back onto the composer idea and had other ideas on that. Ultimately, we didn't really find product market fit. Because again, back to the original question is, it's quite difficult and there's a lot of barriers to break in terms of what people can make out of it. What use do they get out of it? Is it actually getting in the way? Is it actually helping them?

Benoît:
I do think from a design standpoint, there was a lot of benefits from being able to edit straight code component. You get exposed much early on to maybe browser quirks or whatever. Things like that that you do in design is all static, and you get handed over a design from a designer, and then you have to redo everything from scratch. Maybe you just copy some colors and that's about it. But here, you could extract so much more value already out of it. That was definitely one thing that was a bit different.

Ben:
Were you able to take an existing component and then edit it in Modulz or did you have to start from the ground up designing a component in Modulz? I remember that was always something with Wizzy Wig editors where some could edit an existing site but it was always a bit clunky versus if you have start from the ground up in their format, then it usually worked better.

Benoît:
Yeah. No, we hadn't gone that far. We were kind of working within the editor, really. I think like you said, doing it both ways, it's another level of complexity as well that you need to abstract. It's like you have a layer of conversion basically between a component that's been written by someone else. I think some framers try to do that, but even then it's kind of limited. It's very hard to do that, I think, if you want to do it both ways. I think, ultimately the goal that we had was not necessarily have a thing that you can just build and export, and that's it. That's your site that you publish, similar to [inaudible], for example. It was more like a design tool, really a way to... People wouldn't use Figma, maybe they would just use that instead. And then, it would not be the final output, but it would be so much closer already to the final output. It'd be getting into more of the reality of where the medium is going to be in the end.

Speaker 3:
Enjoying the podcast? Consider hitting that follow button for more great episodes.

Ben:
And so, tell me a bit about Radix. So, was that a project that you started before or during or after the development of Modulz?

Benoît:
Yeah. So obviously initially, it wasn't called Radix, but I was hired specifically for that. Basically at the beginning, I joined quite early on when we started to need to build these components to be able to use within our editor or within our design system bill, for example. And so, the whole goal was to build a suit of components like this. They were highly accessible and functional, and these were called Primitives, back then. I mean, they're still called Radix UI Primitives because Radix UI is a bigger umbrella but people mostly refer to it as Radix UI, now. And we went through a few iterations of this over the years, although now it's been out publicly open source for maybe a year or maybe a bit more, now. It's more maybe two, three years old, now. So it was a few different versions, some code in there. It's probably still that old. So yeah, there was a few different iterations.

Benoît:
Essentially, we started from the design system builder point of view where we had a lot of control over the entire end-to-end application, if you will. So we could make a lot of decision in terms of styling, for example. And it was pretty closed compared to what it is today. Today, it's a very open component library. Back then, it was a lot of rules that we could make up and we had our own styling interface and all that. It was not just pure CSS because everything was going through the editor. Eventually, we realized that it was not really going to work like that, because people wanted more control or that kind of stuff. And then, we made a move progressively towards making everything more open. And when I mean more open, I mean in multiple ways. The fact that [inaudible], we wanted to decouple that from the editor.

Benoît:
So we wanted to be able to potentially have people use this components in their own apps outside of the editor, and maybe that would bring them, people back into our editor. That was a way to hook. And then, that evolved into making things as open as possible in terms of have open APIs and be completely unstyled so that people can use any styling library, or Vanilla CSS, or CSS Module, SaaS, or CSS [inaudible 00:10:05], whatever they want. And that led to what it is today, which then at this point is when we decided to do all that. That's when I pitched to the co-founders to go open source with this.

Benoît:
Because back then, it was not open source. So this was a private thing internally, and I thought this is a huge opportunity because we need to do that for ourselves, we might as well just do it for everybody to use our site. And it's going to give us the biggest pool of users to try our components in all different scenarios. We [inaudible] for all our stuff, but you can never do everything. People use your components in lots of different ways that you've never thought about. So you get a lot of benefit from that, and thankfully they were really on board about this. So that's what we did and that was one of the best things in my career, to be honest. That's still to this day, one of the things that gets me the most enjoyment. Working on open source and having this impact not just for the company I work for but for other companies, too.

Ben:
And so, there's a lot of UI components, and frameworks, and component kits and there's a lot out there. So talk to me a bit about what's different about Radix. Where does it fit in well in terms of what type of projects? What do you recommend people use?

Benoît:
Primarily, obviously it's React. First of all, we'll say it's for React projects. Secondly, you're right, there's a lot of component libraries but you can classify them in different areas. First of all, you have a lot of component libraries that you can use straight out of the gate and they're all ready, and they're all styled. Maybe you can theme a little bit, but these are going to be fine for some people that maybe don't care too much about the visual style and just want to be on the UI, and it works. That's going to be things like maybe Chakra UI or things like that. And these are great, but you don't have that much control necessarily over how it looks, or maybe some of the functionality, or extend it, and that kind of stuff. Then you have the other end of the spectrum, which is there are a few libraries that are oriented towards building functional components, accessible components, and make them extendable and all that, and build from scratch. But they're kind of on the end of the spectrum. That's a lot of do it yourself.

Benoît:
You have to assemble all the pieces together. These are things like maybe [inaudible], which are really great from the accessibility standpoint. With Radix, where we fit I will say is we're kind of in a happy middle round where we are completely unstyled. So we are on the side of you can use this in whatever situation you want. We are highly accessible, highly functional, highly reasonable, it's all open. It's an open API. But we also try to make it as easy to use as possible. So the developer experience is one big thing for us, where we don't want people to have to assemble a bunch of things and wire states together, or wire refs and things like that in React. So we try to make it so that out of the box, it just works. All you have to do is add some styles. And to do that, we essentially provide a component-based API, where by default, we have all the parts that you can put together and compose together. And that means you have access to all the elements.

Benoît:
Essentially, you almost have a one-to-one mapping between a POD and a DOM element, almost. I say almost because there are a few cases where maybe there might be one or two new users that are not exposed to you. But that means that you can always attach a ref to something, you can add an extra attribute if you need to. If you need add an extra attribute to target something and test for example. Anything like that. Whereas sometimes, when these things are not exposed, it makes it difficult to work with. I would say that's kind of where we fit and that's kind of main difference between some of these libraries. We are at the level where we always think about... A big mantra that we have is we want to make it work for 95% of the use cases. There's always going to be some strange of use cases, you can't support everything but we always try to make it work for 95% of the use cases.

Benoît:
And that's also true for different levels of skills, in terms of developers. One thing that we noticed is we actually do get a lot of junior developers or people who are starting with React, and they want to do the right thing, use these accessible components, and all that. But sometimes, some of them they don't know much about React, so you'd be surprised by some of the questions that we get sometimes. And so, I can't help but look at this and be like, "Man, if you have to use something where you have to piece everything together, they would be completely lost." So I feel like we hit the right spot in terms of abstraction, if that makes sense.

Speaker 4:
It's Emily again, producer for PodRocket and I want to talk to you. Yeah, you, the person who's listening, but won't stop talking about your new favorite front-end framework to your friends, even though they don't want to hear about it anymore. Well, I do want to hear about it because you are really important to us as a listener. So, what do you think of PodRocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing? Weird little component libraries? How to become a productive developer when your WiFi's out? I don't know, and that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on or tell us we're doing great, whatever. And if you do, we'll give you a $25 gift card. That's pretty sweet, right? So reach out to us. Links are in the description. $25 gift card.

Ben:
I'm curious to have you elaborate a bit on what are some of the challenges in terms of accessibility when you're thinking about building standard web interactions like dialogue, and drop down, and slider, and things that almost every website has. What's hard about making those accessible and how does Radix help?

Benoît:
Yeah, that's a great question. So if anybody's interested, there's actually a great talk that Pedro who worked at Modulz made about this, specifically. I think it was called, "So you think you can build a drop-down." It was kind of [inaudible]. It's great because it shows you essentially what are all these pitfalls that people fall into when they try to build their own, or when they try to build let's say a naive version of it. Essentially, there are so many different things that go into it. There are things like focus trapping, to make sure that the focus doesn't get out of the context that you're in when you're in a dialogue, for example. There's also hiding things from the accessibility tree for screen readers, for example. If as a site user I open a dialogue and I have an overlay, and I cannot interact with what's outside of it, I cannot only interact with what's inside. It should be exactly the same for screen reader user. So things like that.

Benoît:
Keyboard control, being able to operate everything with the keyboard, that's also a big thing. Some users can't use the mouse or things like that. So when you go into drop-down, there's added things like all of the above that we just discussed, plus other things like collision support. These things are all part of accessibility. Some of them are just functionality, but they are part of accessibility in a sense that you're trying to make it so that the component is usable by as many people as possible, in as many situations as possible. So for example, if your screen is smaller and you try to open the thing that's on the right and it can't fade, then you would have to switch to the other side. Things like that. Or that happens more vertically from top to bottom.

Benoît:
All of these things need to be included in these components. And things that you see sometimes, even some of the library dimension is that they offer, for example, the pure accessibility part of it. Things like area attributes and focus trapping, and things like that. But they might not necessarily, for example, provide some of the extra functionality that feel like it's needed for some of these components. Typically, collision handling and positioning, for example. They might just leave that up to you, which is a big gap if you're a user, you're a junior developer and okay, you use that, maybe you manage to build that, but then you still have to build this entire position logic on top of it, use another library, maybe piece it together. So we try to have a solution that encompasses all of these things together.

Ben:
So, if someone out there has a React application, wants to use Radix, what does it look like to get started and what's kind of the adoption story? Can you adopt gradually? You have to jump in all at once, what does that look like?

Benoît:
That's a great question. Yeah. So it's actually pretty straightforward. So we make it, again, developer-friendly in the sense that you don't have to jump all in straight away. Every component is individually versioned. So every component is a single package. And so you can for example, say, "I'm just going to start with the dialogue, a simple one. I'm just going to install the package for the dialogue and then I'm going to start using that. If I'm happy with it, I can then start using all the packages." And we've seen tons of teams doing that. They start with one or two components, and then gradually they start adopting more and more components. Right now, we have maybe 30 components, or something like that.

Benoît:
Quite often, that's how it starts. You start using a dialogue and then, "Oh that's cool, I'll start using drop-down menu." There's some components that get reuse quite a bit like that. But then otherwise, that's it. You install the package, you import in React, you have access to all of the parts, and essentially you compose all of the parts so you can [inaudible]. I'm going to add my dialogue route and then I'm going to add my trigger, my content, my overlay, and you have access to everything. And all you have to do at this point is style it whichever way you want. It can be adding class name if you want. That's all you need, literally. Even just raw CSS.

Ben:
So what's on the roadmap for Radix? What are you most excited about over the next year or so?

Benoît:
So, we've just recently released version one, so stable release. I mean, it was stable for a long time and we just officially moved to year one in terms of [inaudible]. Which was already a great move because we saw tons and tons of teams using it, even though we were still in the beta version ranges and people were depending on it a lot. So this went out I think a month ago, or something like that. And so right now, we are focused on fixing up some of the bugs that came up. Mostly actually, it's more like some extra features that people are needing for some components. Things like deselect for example, which is one of our big components where some people felt that it was a bit too opinionated in some areas, which I agree with. So we are going to try to make it a little bit more open, which is obviously what we try to do most of the time.

Benoît:
Past that, we have a roadmap of some components that we are interested in building. Some of them already started, some of them also even started by the community, which is great to see, as well. Things like menu bar, for example. We have a carousel that was in progress, as well. And after that, it's really about adding features and then adding more components. We tend to prioritize trying to add new components if possible, but obviously these components take a long time to build. So just to give an idea, something like deselect, I probably took months to build that. Three to four months to build just a single component like that. So it gives you an idea.

Benoît:
So sometimes, things can feel a little bit slow. But then, we also have now from the WorkOS side of things, we also tend to try to help that front as well. So one thing that we did recently is, actually just today, we launched a new version of the Docs for WorkOS and so we helped a lot with that, as well. And with that comes for example, trying to prioritize maybe certain features or certain fixes or whatever, that are needed for specific projects. So it's kind of a balancing act between what the community wants, what WorkOS needs, and what we want to work on.

Ben:
So I'd like to understand a bit more about WorkOS overall and in particular, how does Modulz and then Radix all fit into the mission and product behind WorkOS?

Benoît:
So just to be a bit of background I guess, so Modulz was the startup where I was working at and where we created Radix. And we got acquired by WorkOS, essentially, maybe six months ago. And it's quite a nice fit because WorkOS essentially is a very developer-led company, as well, where the whole point of WorkOS is to provide developers with a set of tools to create, essentially SaaS applications. So you have all things from authentication, and SSO, and directory sync, and now we just released audit logs, as well. So all of these tools that are needed for service applications to provide an enterprise-ready software, essentially.

Benoît:
And so, the way Radix fits into that, the goal is to be sort of the de-facto component library to use to build your SaaS application, if that makes sense. Because already today, tons of startups just go straight to React, for example, to build their product. And so, it only makes sense to be able to offer great components to use like that, out off the bat. And we've already seen tons of companies like Vercel and CodeSandbox, and all that, using Radix for that reason. And so, that fits in really well in that sort of approach of WorkOS is providing more and more of these building blocks, if that makes sense.

Ben:
So Benoît, thank you so much for joining. It's been great learning about Radix, and Modulz, and WorkOS and the whole suite, there. So really appreciate you joining and we'll put links to some of these projects in the episode description for anyone out there who's interested in listening.

Benoît:
Great. Thanks for having me.

Speaker 4:
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.