Sunday, August 27, 2023
When NOT to use shadcn/ui?
shadcn/ui works best when you wish to build your UI component library while looking for a good starting point. This means heavy customizations on the components should (and in my opinion, MUST, more on that later) be expected. Suppose you want everything to work out of the box, including a predefined design system and apply relatively minor customizations to the built-in components, then a UI component library like MUI and Chakra UI may give you a better experience.
By the way, this website took the #2 approach and used Joy UI from MUI.
How does shadcn/ui work differently from a UI component library?
Unlike UI component libraries, we are not installing
shadcn-ui as a package and importing components from it, i.e., this is NOT how shadcn/ui works:
Instead, the components' source code is being generated by the CLI and added to the project. They become part of the project source code.
And then the components can be used by importing them from local files as if they are developed by you.
At this point, shadcn/ui's mission is effectively completed. The generated code is now part of your source code. This approach is quite special and has its advantages and disadvantages.
You have full control over the generated code and have the ability to apply any customizations you see fit.
If you are planning to implement your design system, doing so with shacdcn/ui as the base line is very easy. For example, for the
All we need to do is to customize the Tailwind CSS classes in
variantsto customize the button without touching the rest of the code.
- The generated code is part of your source code now, something that you have to maintain and worry about, unlike a package where most of the logic is encapsulated.
- The generated baseline is leaving a lot to be desired, and the users need to know what they are doing to effectively make use of it. This means heavy customization might be required from the very beginning, instead of an incremental process that some may assume. For example, some questionable designs in the
sizeinstead of being a dedicated prop like
iconOnlyor a dedicated component like
destructive(also refers to as
dangerin other libraries) button is a
variantinstead of a
- There is no
successcolor out of the box. In fact, this is the case for the entire library.
- If you prefer to maintain a connection between the customized components and
shadcn-ui, patching will require a considerable amount of manual work, as opposed to just running
npm updateif it was a package.
Although shadcn/ui does simplify the UI creation process in a lot of cases while offering a high degree of customizability, hence the main reason it gets so popular, it is not the silver bullet. Instead, it is a specific tool targeting a very specific audience. It never fits the "this is the best component library" statement and is not beginner-friendly (beginner to FE development) at all. At the end of the day, it is about choosing the right tool for the right use cases.