The whole point of shadcn/ui is that it’s customisable (that’s why the components are copied into your app as opposed to installed from a central npm package).
That's nominally true, but a project using shadcn/ui is nearly immediately identifiable as such because most do not deviate from the defaults it (or Tailwind) provides. A UI for toggling border radius and colour palettes isn't going to help this.
The driving purpose of Tailwind is to provide a massive suite of utility classes to atop a consistent set of design tokens and yet the vast majority of projects using it will be plucking patterns wholesale from TailwindCSS Plus, Flowbite, etc.
Even Bootstrap was designed for customisation but still, a large number of teams who deployed it would stick largely with the defaults. It's just how it goes, and it's a perfectly valid complaint from observers.
I have absolutely nothing against Tailwind and shadcn/ui so don't take this as a criticism. This is aimed squarely at the people who point out that these tools are designed for customisation without acknowledging nearly every deployed example pulls from the same limited pool of defaults, UI components and larger templates. And why wouldn't they, tailored design systems take incredible effort and skill to get right.
The reason why customizing has some mild disincentive is because as you install more components, all the other new components won't be aware of your changes. Otherwise it's a great start for a custom design system.
That's funny. I thought ShadCN was LLM generated when I saw this thread and clicked the link. I didn't realize it was the ancestor of all the other stuff.
We initially looked into using shadcn/radix - but it's quite bloated. Maybe even warranted with all the a11y accommodations - even the official W3C ARIA examples are not straightforward (most of the time).
