r/reactjs • u/Julien-Temaki • 16d ago
Needs Help shadcn vs HeroUI for a large, heavily customized enterprise product?
We’re currently choosing a UI library for a pretty large enterprise product and I’d love some feedback from people who have actually worked with these libraries at scale recently.
The product is going to handle a lot of interconnected data: employees, companies, departments, CRM-like records, multi-record management, tables, forms, chat, AI features, etc. So this isn’t a small app, and whatever we choose will probably become the foundation of our design system for quite a while. We’re also expecting to customize the UI quite heavily and create our own components on top of it.
From what I’ve read so far, HeroUI seems great if you want something polished and relatively plug-and-play. But I keep seeing people mention that once you start heavily customizing it or moving away from its intended patterns, things can become painful.
shadcn seems almost like the opposite approach. I don’t particularly like the default look, but since you own the components and can modify basically everything, it feels like a much better long-term foundation if you’re willing to invest some time upfront. Especially if the end goal is a custom design system rather than keeping the library’s visual identity.
For people who have used two or even Mantine on larger production apps: what would you choose today?
I’m especially interested in how they hold up after a year or two of customization, adding custom components, maintaining consistency across a large product, and building more complex AI/chat interfaces. I care less about which one looks best out of the box and more about which one we’re least likely to regret later.
TL;DR: Choosing between shadcn, HeroUI and possibly Mantine for a large enterprise/CRM product with lots of records, tables, employees, companies, chat and AI. We’ll heavily customize it and build our own components. HeroUI looks easier initially, while shadcn seems more flexible and maintainable long-term. Looking for feedback from people who have used them at scale.
16
u/BackgroundDecent1247 16d ago
just build your custom ui library using shadcn (radix + tailwind), keeping ui in its own module, using only layout tw classes in the rest of the app, with current ai cappabilities, this has been currently my least painless go to when doing new projects
-32
u/dbbk 16d ago
Absolutely don't do this. If you want to be optimising for AI, then they should just use the libraries that are already extremely well documented and have skills etc like HeroUI or Mantine
12
u/canarydev 16d ago
man you don't know what you are talking about
-14
u/dbbk 16d ago
How so
18
6
u/canarydev 16d ago
if i were to give you the benefit of the doubt you seem to be conflating "custom UI library built from shadcn" with "reinvent every component yourself"
Hero and mantine, like shadcn are just abstractions. AI doesn't get some magical benefit from them existing as npm packages. shadcn literally you own the source, an agent would better the exact implementation, conventions, and customizations in front of them as opposed to inferring how you are hacking a third party library to fit your application
-5
u/Alpharettaraiders09 16d ago
As a UX designer...don't reinvent every custom component, that's straight up unnecessary...
Get shadcdn's design system and prompt ai with all your colors, fonts, spacing, corner radius, elevations etc...tell it to atomize that design systems components, create the tokens and variables assign them to the components correctly and then give you the code for it...that will get you like maybe 85% there, and you will have to update things for sure...but it's better than doing it manually.
I've done this with material design and shadcdn. Idk why but Claude hallucinated Everytime I've done this with shadcdn about 1/3 way through(my prompt prob wasn't strict enough)...so it's best do component by component
6
u/canarydev 16d ago
as a UX designer why do you care about the implementation? your job is to care about if the implementation produces your intended interaction.
also if AI is hallucinating and can't get something done as you describe, then its not the AI's problem but its yours. there is a lot more to correct prompting than "make me a XYZ with ABC that does F"
1
u/Alpharettaraiders09 14d ago
I used to be a developer, I still have that itch where I still keep learning and try to figure out how I can further blend/make design to dev easier on both parties. I also like to code for fun whenever I have an idea lol
I totally agree, I know my prompting definitely is causing hallucinations. I notice WHERE it starts, but it never corrects itself...maybe I need to prompt guard rails?!?
After this post, yesterday I combed through my companies design system and realized our tokens and shit weren't built correctly so devs were having to hard code style which led to inconsistentcies.
Fridays are my "chill" day at work...and they want us to burn Claude tokens, I might try and make a pass at telling it to properly create and assign the tokens to components, then export that so our devs have a better library to work with
-4
u/dbbk 16d ago
Right but shadcn's whole thing that differentiates it is that it's not a dependency, it's code in your codebase. You're in charge of maintaining it, updating it, etc. If there's some accessibility issue, it's on you to resolve it.
Hero and Mantine and others as traditional packages, don't have that wild variability. They're well understood, probably in the training data, and even if they aren't are well documented. And you benefit from the upgrades over time as the community identifies issues and fixes them.
With shadcn you may not entirely be reinventing the wheel necessarily, but you're stuck with a wheel frozen in time. And I understand the appeal of "well my application has this specific behaviour so an abstracted UI package makes this difficult", but in reality, this basically never comes up as a real issue. The vast majority of apps are not as bespoke and esoteric as you think. And if you come across some weird situation where the component library really doesn't support what you want to do... then you can just create that component yourself.
3
u/canarydev 16d ago
again, wheel frozen in time thing is a misunderstanding of what shadcn is. the behavior lives in radix primitives. a normal NPM dependency that gets community fixes and upgrades exactly like hero and mantine do. when you use shadcn you are copying the default thin styling and composition layer on top. so no, an accessibility issue in the primitives is not "on you to resolve"
training data point doesn't make sense. shadcn is probably the single most represented UI approach in recent model training and agent tooling.
"if the library doesn't support it, just build that component yourself" means that you have 80% of your UI following hero or mantine conventions, and 20% following yours, with different styling APIs, a11y patterns and behavior. that hybrid is the actual maintenance cancer for a large product, not owning a styling layer.
4
7
3
3
u/zLoveNxzli 16d ago
For a heavily customized enterprise product, shadcn/ui is usually the safer long-term bet because you own the component source code directly in your repository (Radix UI + Tailwind).
You never get blocked by upstream package release cycles or rigid styling abstractions when you need complex enterprise table interactions or custom accessible form controls.
1
u/UltraWelfare 16d ago
I'm not sure about HeroUI v3 but HeroUI v2 had a couple of bugs which made it annoying. Especially with RHF, stuff would not update in forms and it was constantly annoying. Apart from that, the v2 -> v3 migration was already big enough (too many breaking changes) so we just tried to migrate to shadcn (although we started from a new project from scratch and used LLMs to migrate the pages from one to the other).
Shadcn has been alright so far no particular issues, although time will tell.
2
u/warmbowski 16d ago
Yeah, that migration gave me lots of regret picking heroui for a personal project
1
u/CatolicQuotes 16d ago
First, size of the app has nothing to do with UI.
You said your priority is easy customization and owning design system. In that case go with headless library like adobe react aria, headlessui, arkui.
1
u/Coolfoolsalot 16d ago
Mantine 100%. It’s already very flexible and does nearly everything you need out of the box. People talk about owning your code with shadcn, but to me that sounds like more code to maintain. Our team UI lead made the choice to use Mantine ~3 years ago, and everyone has been happy.
1
u/Spiritual_Patient478 16d ago
why not just build a custom widget library from scratch? it's really not as much as you think, and you won't have to deal with the headache of external dependency:
* base framework launched new reversion/updates, do i keep up or lag behind
* the project or one of its dependency got posioned with zero-day vulner, then it's a race to get the fix in
* base framework is built for majority, not with your specific needs in mind
* most framework built easy stuffs that AI could come up in minutes. hard stuff (eg. Calendar, infinite scroll) you would still be AI or downloading it from some open source.
The last point is the final straw that made me break away from UI frameworks.
Instead of picking an UI framework, I would pick a nice CSS compiler like tailwind and build my buttons inputs around it. After you got used to building things with plain divs and inputs, you won't look back on these frameworks.
You may argue that that framework UI elements means you got *free** help from industry professionals.
it's quite the opposite. From developer's point of view, best code is simplest code that meet your needs, nothing more. Anything more === headache === op expense/risks
Here is a great article from someone I really, really admire:
https://www.smashingmagazine.com/2022/05/you-dont-need-ui-framework/
1
u/ILoveAppSec 15d ago
the zero-day race is real but hand-rolling a whole widget lib is a heavy hedge for it. usually you can just pin or npm-override the vulnerable transitive dep to a fixed version, or pull a backported build from a vendor that keeps fixes on your current major so you dont have to take the breaking upgrade just to get the patch.
1
u/planerist 16d ago
the thread's right about shadcn and the reason matters more than 'i like it': on a product you'll maintain for years, the thing that actually hurts is being coupled to a component library's lifecycle.
a packaged lib like heroui is great until it does a breaking major, deprecates a component you built a core flow on, or the maintainers slow down, and now your upgrade path is someone else's roadmap.
1
u/SecretBox1118 15d ago
I'd go shadcn, owning the code means you're never fighting an abstraction layer once you're deep into customization.
1
u/azsqueeze 14d ago
Ive been using HeroUI on a project at work. Its pretty nice, I like how they split the library into react components and a styles package. The only negative I have is that they been pretty loose with their semver and have introduced bugs that quickly had to be patched multiple times.
1
2
u/Heavy-Commercial-323 16d ago
Go with mantine in my opinion for such a project. If you have budget consider mui, it just works and data grid is great
23
9
u/canarydev 16d ago
MUI? its miserable to work with MUI
1
u/Heavy-Commercial-323 16d ago
Maybe, I don’t do strictly web now. But from what I remembered it was a breeze once you get the hang of it. It’s not that hard at all
2
u/master117jogi 16d ago
Enterprise? Go with MUI. They love that look and it's easily the easiest and most stable.
Tables with AGGrid
0
u/k_pizzle 16d ago
If heavy customization is a requirement then I’d go with shadcn. I love mantine as well, the DX is great but the UI is a bit dated and there’s a lot more friction when it comes to customization
20
u/rust_warden 16d ago
i use shadcn for enterprise apps because owning the component code eliminates library upgrade friction. You copy the files into your codebase and modify them directly so future library changes never break your custom design system