Shadcn/ui—a hugely popular open source React UI component library—is a critical piece of frontend infrastructure you’ve never heard of, and AI app developers are taking notice. For folks outside of the frontend and design world, a UI component library is a collection of pre-designed, reusable UI elements (buttons, forms, and navigation bars) that can be used across various projects. The intention of these is to ensure consistency and efficiency in development. With 85.5k GitHub stars, shadcn has become a dominant force in this market, and in the AI “vibe coding” era it is only positioned to grow. That’s why according to Tony Dinh, founder of TypingMind and DevUtils, shadcn is the “default UI lib of LLMs.”
Being the default UI lib of LLMs is incredible 🫡 Loving the shadcn components in my latest project.
— Tony Dinh 🎯 (@tdinh_me) January 25, 2025
Bolt, Lovable, and Vercel’s v0 all build on shadcn. Lovable’s blog, for instance, announces that “Shadcn is now the default design system for new projects.” Shadcn also underlies the UI libraries of devtools including Supabase and Auth0 that are looking to remove friction in connecting these vendors’ backend services to the frontend. When Paul Copplestone, CEO of Supabase, recently announced the creation of Supabase UI Library I reached out to ask why the team chose shadcn. According to Ivan Vasilov, frontend developer at Supabase:
The main reason why shadcn approach is a good fit for us is that it transfers the ownership of the code to the user.
if the user wants to customize the Ul, they don’t have to wait for us to implement className on specific components or add specific props. If we add a new auth option somewhere, the user doesn’t have to wait for us to support it, they can just change it, it’s their code.
The previous approach (https://supabase.com/docs/guides/auth/auth-helpers/auth-ui) was deprecated mainly because we owned the code for the UI, so it was an endless wishlist for customizing the Ul and a maintenance burden for us
The part where it’s becoming a standard for distribution, theming and component API is a huge bonus.
Lots to chew on in this rationale, which I get into below, but I argue Supabase’s experience around UI libraries points to larger trends in design systems, single page applications, and AI coding.
This post takes a tour through the state of React UI component libraries (sometimes called “registries”) by not only discussing where these tools came from, but we will also take a look at how new AI-powered frontend tools are shaking things up. We’ll cover a bit of history, poke fun at the never-ending quest for the perfect UI component solution, and hopefully get a clearer picture of why UI libraries continue to matter.
It was so fun working on the blocks, we had to research every little shadcn did in his library: How do you do hooks? How do you make the file install in the right place?
shadcn/ui is a great library. I can't wait for it to become the lingua franca for distributing UI components. https://t.co/fJikGVcGaK
— Ivan Vasilov (@ivasilov) March 31, 2025
Taxonomy of UI Component Library Types
Before discussing how we arrived at the shadcn era, let’s lay out the types of UI component libraries available today, the developer needs each one fills, and examples:
- Headless: Provides reusable, unstyled components with a strong emphasis on accessibility and functionality. Headless libraries often include accessibility features and focus on the underlying structure and behavior of components, while unstyled libraries may or may not prioritize accessibility and may be focused more on offering a foundation for building custom UI elements. (Adobe’s React Aria, WorkOS’s Radix primitives, Tailwind’s Headless UI, Downshift)
- Unstyled: A general unstyled component library is simply one that lacks predefined styles, allowing developers complete control over the visual presentation. It offers basic building blocks or primitives that offer the essential behavior and layout of UI components without any built-in styling. (Material UI/ MUI [created by Google], React Bootstrap, Shoelace, Open-Dash, Open UI, Base UI, notyf)
- Styled UI: A set of pre-built UI components with built-in, although often customizable, styling that enables developers to rapidly create interfaces with a uniform visual appearance out of the box. (shadcn, Tailwind Plus, React Aria starter Kit [for Tailwind or Vanilla JS], Melt UI [for Svelte], Chakra UI [for Next.js RSC], Ant Design, Mantine)
- Full UI Kits: Developer-friendly reusable UI components, templates, styles, and other digital assets. (Frames X, UntitledUI, Disy Design System, Cabana, FlowBite, Tailwind Catalyst)
- Design Systems with UI Components: Company-specific design systems often contain UI components. (Google’s Material Design, AWS’s Cloudscape, Adobe’s Spectrum, Microsoft’s Fluent, IBM’s Carbon, Salesforce Lightning)
History of Unstyled React UI Libraries & Design Systems
To appreciate the current UI component library landscape, it helps to know how we ended up with so many React UI solutions in the first place. In the early days of React (circa 2013-2015), developers were coming off years of using general web UI toolkits like Twitter Bootstrap (the OG CSS framework) and jQuery UI. While the JQuery library handled DOM manipulation and event handling, Bootstrap emerged from the need to make websites responsive on different screen sizes and browser types. React was all about components, which are reusable and self-contained pieces of code that define a part of the user interface. However, because Facebook/Meta failed to provide an official React component library, the community had to step in to build them.
Material-UI (MUI) was one of the first big React component libraries, bringing Google’s Material Design components to React. Launched in 2014, it quickly became popular for its comprehensive set of pre-styled components and cohesive design. Many React apps in the late 2010s had an unmistakable Material look thanks to MUI (and yes, many still do). That’s because MUI is notoriously difficult to customize. This emphasis on consistency and productivity was both a boon and curse. Using them meant you didn’t have to reinvent the dropdown or datepicker every time, but every dropdown or datepicker looks identical.
Other early players like Ant Design (from Alibaba’s Ant Financial), Semantic UI React, and Palantir’s Blueprint also gave developers ready-made components to speed up development and make interactions and visual experiences more reliable. In 2017, the Palantir blog reflects on the problems that motivated its design team to create Blueprint:
Our work was siloed: platform teams were not leveraging each other’s work, forward-deployed engineers built one-off solutions, and our designers and product engineers often ended up reinventing the wheel. As a result, our ecosystem of applications lacked a cohesive user experience, inefficiencies slowed us down, and the quality of our work suffered.
By the late 2010s, nearly every company with a sizable frontend React team was either using a third party UI library or building their own internal design system that also typically have component libraries (Google’s Material Design, AWS’s Cloudscape, Adobe’s Spectrum, Microsoft’s Fluent, IBM’s Carbon, Salesforce’s Lightning). This era was all about themes and customization APIs–libraries like MUI, Ant, Chakra UI, and Semantic UI, offered theming options to let you at least swap colors and fonts to match your brand. The benefits were clear: speed, consistency, and not having to be a CSS guru to get a decent-looking app with the additional benefits of accessibility and community support.
History of CSS Frameworks & Headless UI Libraries
It is important to note that UI component libraries were not the only way frontend engineers took advantage of out-of-the-box styles. In 2019, Adam Wathan, Jonathan Reinink, David Hemphill, and Steve Schoger released the Tailwind CSS framework. The idea was that instead of pre-made components, Tailwind provided low-level CSS classes to design anything by composing tiny classes. This was a paradigm shift. What Tailwind provides is the lower level customizability that developers missed with MUI. In the past five years, Tailwind has amassed a devoted fanbase, with the r/tailwindcss subreddit boasting 33k members. Tailwind enthusiasts love the control it offers while eliminating the context-switching of jumping between CSS and JSX because you can do it all in your markup. But Tailwind also has critics. Jared White, a web developer, complains that it generates “ugly-ass HTML,” and, similarly, Hacker News user dbbk calls it a:
hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components
As with most things in devtooling, it really comes down to preference. But the rise of Tailwind CSS and similar approaches signals a need within the community for improved control. This demand led to “headless” component libraries that provide functionality and structure (for instance, HTML + ARIA for accessibility), while leaving the styling up to the developers. Unsurprisingly, considering its provenance, Tailwind’s Headless UI (27.2k GitHub stars) is among the most popular of these approaches, compared to Radix primitives (16.9k GitHub stars), Adobe’s React Aria (13.8k GitHub stars), and Downshift (12.2k GitHub stars). All endeavor to hit the sweet spot of accessible, battle-tested component logic (dialogs, menus, etc.), while also bringing your own styles via CSS or a utility framework like Tailwind. At their core, headless UI component libraries cater to teams that want to build a unique design system without coding every component from scratch. The advantage is to avoid becoming locked into Material Design or any preset aesthetic by adopting the skeleton, and you fleshing out the styles.
Recently, a new approach to UI component libraries has emerged, shifting the focus from mere ‘control’ to a deeper sense of ‘ownership’—a quality highly valued by both developers and vendors.
Shadcn UI: Design System as Code
In 2023, a project called shadcn/ui created by shadcn, currently a design engineer at Vercel, took the React world by storm. Instead of publishing a package of components to npm, shadcn/ui provides a website and CLI that lets you choose components and add the source code into your project. It’s like copying snippets from StackOverflow, except those snippets are your whole design system. Shadcn’s components are built on Radix UI primitives for accessibility and use Tailwind CSS for styling. Essentially, shadcn/ui gave developers a beautifully designed starting point with full code ownership. Once you add it, it’s your code to tweak.
Shadcn uniquely allows users to copy the code directly into their own repositories. This approach flips the script on traditional libraries, which are typically installed via npm and contain pre-built components that you can use via imports. Updates come from the package maintainer meaning that you override or theme by way of provided APIs, but you don’t usually fork and edit the library’s internal code. Sure, this means that developers using shadcn are on the hook to maintain this code, but it eliminates the heaviness and complexity of dependency bloat.
So why has shadcn been so wildly popular? Opinions are rampant, but tend to focus on the idea of code ownership. According to Manupa Samarawickrama, a web developer and blogger:
In essence, shadcn/ui is not just another component library but a mechanism to declare a design system as code.
The “as Code” movement, which includes Infrastructure as Code (IaC) and Docs as Code, emerged because practitioners want to design, build, and deploy applications by following established software best practices (versioning, provisioning, testing). Because UI components are fiddly, developers see the decoupling of style from implementation that shadcn offers as an advantage. As Samarawickrama explains:
Building custom components is usually not difficult to implement at the surface level using modern UI frameworks. But most of the time these implementations of custom components tend to overlook some very important aspects of the behavior of a UI component. This includes behaviors such as focus/blur state awareness, keyboard navigation and adhering to WAI-ARIA design principles. Even though behaviors are very important to enable accessibility in our user interfaces, getting these behaviors right according to W3C specifications is a really hard task and could significantly slow down product development.
Like the advantages of headless UI libraries, what shadcn does is ensure the uniform, performant interactive frontend designs. Theo builds on this idea of shadcn supporting “design system as code” when he suggests that it effectively bridges design paradigms for modern CSS Solutions which include what he terms:
- CSS++: solutions that extend CSS, (shadcn is built on Tailwind)
- Behavior Libraries: solutions that provide needed behaviors like accessibility and browser support (shadcn is built with Radix)
- Style Systems: pre-built styles (shadcn offers styled components)
In short, shadcn/ui redefines how developers think about component libraries by putting control and responsibility back in their hands. By combining accessible behavior primitives, utility-first styling, and full code ownership, it aligns perfectly with the growing “as Code” movement. Rather than abstracting design systems away, it embeds them directly into your project in a manner that is flexible, inspectable, and entirely yours.
AI & The Future of UI Component Libraries
Today UI component libraries offer a convenient shortcut to a decent UI without hiring a dedicated design team. They have become so important to frontend development that some engineers claim to base their entire choice of framework upon component library support. As one Reddit user explains:
The only reason I still use React over Svelte is because of how good Mantine is
This is huge. For the trade-off of taking advantage of effective, pre-built UI components, developers are willing to forego a JS framework they prefer. While in a sense this Reddit user’s declaration echoes conventional wisdom about the importance developers place on integrations, ecosystems, and community, it simultaneously advances my ongoing claims about the Frontend Kingmaker. Frontend engineers—inclusive of JavaScript developers, designers, and UX—are now making architectural and purchasing decisions that will impact all layers of the stack.
As the importance of LLMs to software engineering accelerates and expands, the place of UI component libraries will become even more ensconced. Component libraries are a boilerplate and abstraction, and this is precisely the type of thing nonprofessional “vibe coders” need to get up and running quickly. Why are AI + shadcn an especially compelling pair? Because developers using shadcn have all the code, they can ask AI code assistants (GitHub Copilot, Cursor, Augment Code) leveraging any model (Claude, ChatGPT, Gemini, Llama) to refactor or customize components. I already mentioned that Bolt, Lovable, and Vercel’s v0 all build using shadcn, but this is just the tip of the iceberg. It is also worth mentioning that Convex provides templates leveraging shadcn, while Replit offers a shadcn UI boilerplate. Devin’s docs also share that:
Devin can deploy frontend applications using a pre-configured template that uses Vite, TypeScript, Tailwind CSS, and Shadcn.
In other words, shadcn’s code-first approach, which is transparent, flexible, and ready to be shaped by any model you throw at it, makes it well suited for AI-assisted development.
One thing that does concern me about our shadcn-enabled future, is the seemingly diminishing role of design teams it seems to herald. It’s no secret that developers and devtool vendors sometimes seem to have an aversion to hiring actual designers. In our age of lean startups this makes some sense, but there is a real danger to eliminating human designers entirely. Gutting UX and design teams will not only doom our apps to an ugly, one-size-fits-all appearance, it also stymies innovation. As Hacker News user notes:
the developer in me, who realizes how bad we are at design realizes shadcn/ui is terrible for 99% of people using it. They don’t have a design system, don’t know what that even means, and their sinful hands should not be tweaking any UI libraries, at most being limited to modifying a rich set of theme tokens that force consistency… not touching individual components or copying in random cruft with hard coded gaps between elements.
Amen; sinner (it’s me) roundly admonished.
To wrap up, the React UI component library landscape in 2025 is rich and moving fast. We’ve evolved from the “grab Bootstrap and call it a day” approach to a sprawling, nuanced field where developers choose from a palette of options: fully-featured libraries like MUI, headless kits like Radix, copy-and-own solutions like shadcn for ultimate control, and now AI assistants to glue it all together. I, for one, fully expect this space to continue growing rapidly. Perhaps the next big thing will be AI-generated design systems (not just components) or some breakthrough in how we share and distribute UI code. Maybe React 20 will include a standard library of components. I’ll leave predictions for a future post, but in the meantime I can confidently say we are living in the shadcn era.
Disclaimer: IBM, Google, GitHub, Amazon, Microsoft, and Salesforce are all RedMonk clients.
No Comments