[notpushkin]

I’m leaning towards vendoring for all my new projects.

Grabbing an off-the-shelf UI library is easy in the short term, but it’s usually overcomplicated, implements things I won’t ever need, is hard to tweak if/when you want to distinguish your app from the thousand others using the same library, and when you do decide to upgrade it, all your tweaks break in subtle ways.

What I think would be the best approach is building your own UI library. You own it, you get to reuse it across different projects and maintain the same visual style (if desired), and you add features when you need them.

[dsego]

> building your own UI library

It's one more thing to maintain, and it's also difficult to push back on things. If you use off the shelf components it's much easier to say to designers and managers that a UX pattern is not available or not valid. You can point to the mature well known community owned UI library you use and make it authoritative. It's harder to do it if you build your own, suddenly each designer and developer is throwing things in there, adding features etc. It's also difficult to agree on the structure, so the components are well thought out, flexible, but also not so flexible to lose semantics. It's not an easy job, do you use slots, composition, rendering callbacks, there are too many decisions and you spend time building the UI library instead of actually shipping features.

[notpushkin]

It is true, yeah. But it allows you to own the brand identity, which is kinda useful if you have a brand.

I think we’ve found the holy grail with one of my clients recently. Our UI kit follows https://mui.com/ wherever makes sense, but we implement the components ourselves. This means (1) we don’t have to make too many architecture decisions – we just do whatever MUI does, and (2) it’s fairly easy to push back against adding features that don’t add a lot of value and deviate too much from, well, whatever MUI does.

[threetonesun]

Odd to me when I read stuff like this but also posts about how AI is making everything trivial. Surely a thing that almost every company did in the early 2000s should not be hard today, but of course today you can’t just write HTML + CSS, you must consider every front end framework introduced in the last decade.

[dsego]

I remember the 2000s web, it was primitive. It's not hard to combine some html and css, it is hard to support more complex dynamic actions and components, all with consistent theming and behaviors and have them composable and reusable.

[jvorick]

To me, that's the value of shadcn (conceptually) - it's nothing more than a tool to bootstrap your own UI library.

It let's you copy in snapshots and change/edit/refine as you go. You own the UI kit the moment you copy it in. I see Shadcn 'upgrades' as nothing more than a stranger's PR to my UI kit, which usually means useless noise, unless there's a specific feature/bug that I need.

[notpushkin]

Honestly that’s about the only thing I like in shadcn. It makes scaffolding your UI kit extremely easy, but then you own it and can extend it in whatever way makes sense for you. Unfortunately I’m allergic to Tailwind, and React-only makes it a no-go for me, too :(

There are alternatives, of course, but what I’d like to see is a kinda unified component API spec that you can implement however you like, which both humans and AI can pick up without having to learn whatever idiosyncratic props you might have chosen. So I guess, I’d like to see other libraries use shadcn props with “sane”¹ implementation under the hood?

(¹ – in my case, just plain old Svelte components with inline CSS and/or CSS modules :-)