I think these are more useful as baselines than as final destinations, and I expect production users to customize them far more than options in components.
I also separately don't really believe in traditional components anymore, code is cheap. The value in these components is that I took the time to pixel match a bunch of the CLIs, not the specific interface used to integrate them.
ShadCN components have you copy the component code into your codebase, you own it. They come with the ability to configure arguments, but also because the code is yours its expected that you change the internal logic/styling/structure of the component.
I believe in the era of AI code the ladder just makes more sense.
I think shadCN has its place for sure but I’d always advocate for Mantine and css modules anywhere early enough to use premade UI solutions.
That’s a common misconception/myth/lie that doesn’t seem to want to go away even though Shadcn is more honest about it these days.
You don’t own the compenents, and you don’t copy the component code into your codebase. The components are Base UI (and previously Radix) And they’re imported like any other.
What you’re copying is a thin styling wrapper, just the same as you can use to restyle “traditional” components.
The difference is that you have to provide all the styles, rather than just overrides, which can be both a blessing and a curse.
When you import shadcn components you can rebuild them however you want, thats the point.
Why not use BaseUI directly?
In the long run I think most UI will be BaseUI/RadixUI + Component and style guides, prompts, and traditional packages will no longer be relevant.
What Shadcn gives you is a layer of abstraction that separates the underlying (imported) components from the code that consumes them, so you change your button in one place. It’s exactly how better frontend teams consume just about any component library, Base UI or otherwise.
Shadcn really is a bit of a nothing burger, or rather it’s a bit of soggy lettuce between the meat and the bun.