What is the different between Radix Themes and Shacdn?

[nnhjs]

I want to choose a ui library for my side project but I am considering between Radix Themes and Shacdn. Both is based on Radix Primitive. Help me explain advantages and disadvantages. Thanks.

[andrecasal]

Radix UI is a low-level library focused on accessibility, meant to be composed into higher-order components that abstract away its details.

Radix Themes is a good attempt at abstracting away these low-level details, but doesn't enforce the usage of utility classes or any other styling solution. The documentation shows it being used with a vanilla CSS file for each component. According to @vladmoroz, you're meant to decide on your own styling solution. It also doesn't have some components that Radix UI has, like the Accordion component, which is confusing.

shadcn/ui is also awesome, but it's mostly just a styling layer on top of Radix UI so it inherits most of its low-level complexity. Some components abstract away Radix UI's low-level complexity, while others add unnecessary complexity, making it somewhat inconsistent.

Reach UI stopped being developed by Ryan due to Covid.

I'd recommend shadcn/ui which uses Radix UI internally for now.

[vladmoroz]

I want to choose a ui library for my side project but I am considering between Radix Themes and Shacdn. Both is based on Radix Primitive. Help me explain advantages and disadvantages. Thanks.

As a maintainer, I'm biased, but:

If you like Tailwind a lot and want to build your own details on top of a minimal styling, go with shadcn. It's a solid choice.

If you want to build with components that look professionally-designed from day 1, go with Radix Themes. We focus more on the fine design details and try to provide a more complete, coherent experience with the components that we do have. Radix Themes comes with an extensive color and typographic system that takes care of many advanced details we haven't seen anywhere else. Our layout ergonomics are more similar to Theme UI than Tailwind's utility classes, and we believe this layout style leads to a more maintainable UI down the line.

We also don't suggest a particular styling solution for your custom components, so you can use plain CSS, Tailwind, CSS-in-JS, anything really.

---

@andrecasal this isn't a good place to promote your stuff. This "comparison" you posted lacks understanding of all 3 libs you mentioned, and the tone and remarks are insensitive.

[jonschmidt]

We'll mention styling in the docs when we have the time (and see the demand) for a more comprehensive a guide about building your own components on top of Radix Themes.

@vladmoroz would love to see this, we are building our own component library on top right now and we could probably settle some debates this way 👍

[vladmoroz]

@jonschmidt what are you debating? Would love some datapoints.

[jonschmidt]

Most of the debates are not necessarily specific to radix themes (e.g. when to add a custom prop vs rely on css), but one might be whether we should just extend the existing radix props or hide them behind our own. Right now we have settled on extending them, and then providing our own defaults when they are not provided for the sake of speed.

Also I think I would just be interested in what your team would consider a clean implementation here.

I can provide a couple data points as to what we have found useful in our own custom components so far. We have only created components for Heading and Text, and mostly because

• we do not want developers to have to choose between 9 different sizes, we only need about 4 or 5 (and they have more descriptive names for ease of use)
• in certain places (our marketing site e.g.), our texts should have different sizes for different breakpoints, so we made a custom text component that is naturally responsive

We only started doing this a little while ago so I am sure more things will pop up.

[vladmoroz]

Gotcha, we have a similar situation using Radix Themes to power the design system at WorkOS.

We don’t use all Radix Themes components directly—most are re-exported as-is, but some have a wrapper component with a narrower set of variants to choose from.

For example, we use all the typographic components directly because we use sizes 1-7 in the product anyway, and nobody has tried to use Text size 8 or 9 so far. We only have a few text-based components like Page Title or Subtitle where we wanted to lock in a specific size, weight, color, and behaviour across breakpoints, e.g.:

---

However, for some components, we just combine the variants the way it makes sense for our design.

Here’s our Button that is based on the Radix Themes button. Variants, colors, and the high contrast option are pre-combined to limit the possible number of the design combinations.

You can see it also does a few fancy things on top of the standard button. This is what all the possible design options look like:

---

I think you’ll have to decide for yourself based on what makes sense given the team you have and the products you build. The right and wrong ways to do that will depend entirely on that.

[jonschmidt]

Cool, very helpful!

[vitalijalbu]

hi guys, any thoughts about using radix-theme and tailwind? basically i hate separated libraries 😅

[jonschmidt]

I am quite interested in this too. I absolutely love Themes, and I wish I had no need to anything else, but in my work, speed is crucial, and at times I have needed components / behaviors that Radix does not provide, and I have ended up using shadcn, and have fallen further into using tailwind for quick customizations as I can avoid inline styles. But currently it feels a bit weird, and even with https://github.com/viktorbonino/radix-themes-tw, I cannot seem to get the level of sync between the two themes. Sorry this is kind of a non-answer, but I am interested in getting better here.

[vitalijalbu]

yeah, that's the reason i thing i will go with shadcn, i love radix but my team is focused more on tailwind.