Introduction
In the past two years, shadcn/ui has emerged surprisingly in the frontend community, making me reconsider whether UI component development is truly finished.
The current perception of UI components in the frontend world:
- Companies open-source their own design systems, yet face criticism for being KPI-driven "reinventing the wheel" products
- Building UI components is seen as a 0-to-1 process with no room for further value creation
In this seemingly "saturated" field, shadcn/ui still finds its value in two key areas: open discussion of best practices, and establishing freedom and control.
The Self-Proving Trap
Everyone needs their own component library. Developers spend time reinventing the wheel, as if only through this can they prove their value. Everyone claims their business is different, making it "easy to justify" rebuilding everything.
I believe this is a self-proving trap.
shadcn/ui doesn’t fall into this trap. Its tagline is "Build your component library" — at most, it claims to be "Beautifully designed components."
Curated Open-Source Composition
Rather than building everything from scratch, shadcn/ui curates existing open-source solutions:
- Calendar: React DayPicker
- Chart: Recharts
- Table: @tanstack/react-table
- Form: react-hook-form + zod
- Toast: Sonner
- Drawer: Vaul
It openly tells you: these components aren’t written by me, and I’m not a complete design system. This unconventional attitude makes me reconsider: the purpose of building UI isn’t to prove your development skills, but to create better UI itself.
Many developers focus solely on efficiency when thinking about UI component value. But today’s component developers often lose sight of the fundamental goal: creating excellent UI.
Freedom and Control
From a component user’s perspective, shadcn/ui serves component developers, not pure users. If you only want ready-made solutions and maximum efficiency, choose Ant Design. That’s perfectly normal.
The Moment of Ownership
But if you care about UI or need design customization, try npx shadcn init in your project.
Everything you’ve installed before goes into node_modules, but shadcn/ui injects directly into your project. In that moment, you gain a new sense of control over components.
Because it becomes your source code, you develop control over and attention to the UI.
A Different Relationship
With Ant Design:
- Read Props documentation
- Use CSS magic to override
- You’re always accepting
With shadcn/ui:
- Source code is your source code
- Styles are your styles
- You own the implementation
This establishes freedom and control.
Design and Implementation Cannot Be Separated
shadcn himself says:
The design of your components should be separate from their implementation.
However, I disagree — design and implementation certainly cannot be separated. Components define interactions. Interaction is part of design, not just implementation.
The Ecosystem
Recently, distinctive UI component libraries have emerged:
- Magic UI: Modern animations and effects for SaaS products (150+ animated components)
- 8bitcn-ui: Retro 8-bit aesthetic with modern accessibility (12 themes: Sega, Gameboy, Nintendo, etc.)
- v0: AI-powered generation using shadcn/ui patterns
- 21st.dev: Community-driven component marketplace for React and Tailwind components
These prove that building UI components is truly not finished yet.
Meanwhile, I’m also a partner & ambassador at 21st.dev, contributing some interesting components.
When to Choose shadcn/ui
✅ Choose shadcn/ui when:
- You want full control over component implementation
- You care about UI quality and design customization
- You want to understand how your components work
❌ Skip shadcn/ui when:
- You need maximum speed (choose Ant Design)
- You have zero interest in customizing UI
- You prefer traditional package management
Conclusion
The emergence of shadcn/ui signals that UI component development is far from finished. The innovation isn’t in building yet another button component — it’s in rethinking how we deliver, customize, and own the components we use.
Perhaps the real value lies in:
- Transparency over abstraction
- Ownership over convenience
- Composition over comprehensiveness
- Discussion over dogma
shadcn/ui doesn’t claim to be the final answer. Instead, it opens up questions we thought were settled. It reminds us that in software development, very few things are ever truly "done."
The future of UI components is about creating better conversations, better defaults, and better ways for developers to own their craft.
"The purpose of building UI isn’t to prove your development skills, but to create better UI itself."