HeroUI is what NextUI became. The rename caught a lot of projects mid-upgrade, and it left two questions behind: whether to follow the new name, and whether a packaged component library is still the right shape at all now that the copy-the-source model has taken over.
What actually changed
The rename is the visible part. The more consequential difference is architectural: HeroUI is a packaged library. You install it, you configure a theme, you use its components through a prop API, and upgrades arrive as a version bump.
That is the opposite of the shadcn model, where the CLI writes source files into your repository and there is nothing to upgrade. Neither is wrong, but they pull in opposite directions, and a project that mixes them ends up with two theme systems and two ideas of what a Button is.
Staying with a packaged library
There are good reasons to. A versioned dependency means fixes and accessibility improvements arrive without anyone rewriting a file. A documented prop API means a large team builds the same way without a review process to enforce it. And a theme system means design changes land in one place.
If those are the properties you want, HeroUI is a reasonable choice and so are MUI, Mantine and Chakra. The cost is the same in all of them: you can change what the API exposes and nothing else, and heavy customisation turns into a fight with the library rather than an edit to a file.
Moving to the copied-source model
If the reason to leave is that the design is a differentiator, the move is not a swap - it is a rewrite of the visual layer with the behaviour kept.
The path that works: take the primitives from shadcn/ui, which are built on Radix and give you the same behavioural guarantees the packaged library was providing. Take the product surfaces from one general registry so forms and tables stay consistent, as covered in the registry landscape guide. Take individual components for anything meant to stand out.
Expect the theming to be the work. Component behaviour maps almost one to one; a theme object does not map onto CSS variables and Tailwind classes without decisions.
![Calendar [React Day Picker] by originui](https://cdn.21st.dev/cdn-cgi/image/fit=scale-down,width=640,quality=75,format=auto/https://cdn.21st.dev/user_originui/calendar/default/preview.1737991983843.png)
The middle path most teams take
Keep the packaged library where it is already working, and use the registry model for new surfaces that need to look like yours. It sounds like the worst of both, and it usually is not, because the two rarely meet: the marketing site and the new dashboard can happily be built differently from the eight-year-old admin panel.
What does not work is mixing them inside one screen. Two focus treatments, two spacing scales and two sets of radii are visible immediately, and the fix is always to pick one per surface.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| HeroUI | A packaged library with a theme system and a stable API | You customise only what the API exposes |
| shadcn/ui | Owning the source, changing anything | No upstream fixes, no version |
| Radix / Base UI | Behaviour when the design system is entirely yours | You write every pixel |
| 21st | Components in the copied-source model, with live previews | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a component, get the previews inline, and let the agent write the file.
Browse the registry directory →
Frequently asked
- Is HeroUI the same as NextUI?
- HeroUI is what NextUI became. The rename is the visible change; the architecture is unchanged, and it is still a packaged library where you install a dependency, configure a theme and use components through a prop API.
- Should I move from a packaged library to shadcn?
- Only if the design is a differentiator. A packaged library gives you a versioned dependency, a documented API and a theme system, and takes back the ability to change anything the API does not expose. If heavy customisation keeps turning into a fight with the library, that is the signal to move.
- How hard is the migration?
- Component behaviour maps almost one to one, because both sit on similar primitives. The theming does not: a theme object does not translate into CSS variables and utility classes without decisions. Budget the visual layer as a rewrite and the behaviour as a port.
- Can I use both in one project?
- Across surfaces, yes, and many teams do: keep the packaged library where it already works and build new surfaces the other way. Inside one screen, no. Two focus treatments, two spacing scales and two sets of radii are visible immediately.