Is shadcn overcomplicated and difficult to use?

Discussion
1

Drop your opinions, please. I found it difficult to use and customize.

2

I found the opposite; it’s easily extendable and customizable.

3

Peyton said:
I found the opposite; it’s easily extendable and customizable.

I’d like to discuss this with you more (if you don’t mind). I always give it a chance, but at the end of the day, I just give up and switch to another library.

4

@Brady
Why don’t you share what you found difficult?

5

It’s one of the easiest to use since you literally just copy the code into your project.

6

Jaden said:
It’s one of the easiest to use since you literally just copy the code into your project.

That’s part of my issue with it; you don’t just copy the code. You still need to install some Radix components, copy/paste other components it depends on, and sometimes add utility classes. It’s simple enough usually, but not as straightforward as they claim.

7

@Blake
The CLI does all of that for you, though.

npx shadcn add sidebar, for example, copies everything for you and installs dependencies.

8

Haven said:
@Blake
The CLI does all of that for you, though.

npx shadcn add sidebar, for example, copies everything for you and installs dependencies.

Does it? I tried this recently, and it only added the sidebar files, not the dependencies. I had to install those one by one. Seemed odd.

9

@Blake
You realize they have a CLI that handles all of this for you, right?

10

shadcn/ui differs from component libraries because it allows ownership of the code, giving you freedom at the expense of responsibility. We faced limitations with other libraries, often needing to create separate components or modify existing ones. Ultimately, we created our own component library along with a design system. If shadcn/ui had been available earlier, I’d have certainly used it as a starting point.

11

I had minimal customizations, but it was very easy to use for my first Next.js project. The table with sorting and filtering is complex, and the documentation was a bit rough. Examples for each feature exist but lack variations. However, since the table is built on TanStack Table, referencing its documentation is helpful. The copy and customize paradigm works well.

12

The examples aren’t very accessible. Here are a few issues I spotted:

  • Card examples aren’t well structured and don’t present as self-contained components in the accessibility tree.
  • Graphs lack accessible equivalents; they’re just empty picture nodes.
  • Many images (avatars, logos) use a mix of <img> and <svg> without alt text or text equivalents, yet they’re not hidden from the a11y tree.
  • Form fields lack proper button text and correct element types (e.g., text fields used for URLs, number type for credit card numbers).
  • The mail app example lacks semantics to connect parts logically in the accessibility tree.
  • Tasklist tags aren’t identified as tags, only visually.

This component library needs significant work to improve accessibility.

13

I love it. I use it as inspiration for building components on top of Radix, which I truly enjoy. It allows for creating standardized components. Although shadcn doesn’t provide everything I want, it, along with Radix, enables building the more opinionated and personalized components that I need.

14

I ditched it because I didn’t want to deal with their headless part and the poor documentation that doesn’t expose all attributes/props. After hitting several roadblocks, I switched to DaisyUI and rebuilt things myself (Svelte port of shadcn).