-
-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to shadcn components? #527
Comments
Good idea to discuss about UI libraries. I reviewed libraries and here is my analysis: Shadcn UI:
After considering these options, I believe PrimeVue might be the best choice for long-term. |
@sreeharsha-rav I think your analysis fails to take into account the fundamentally different nature of shadcn (vendoring components instead of depending), which leads to your review not being very fair. "Fewer commits" can also be good, actually (and what I would expect/want). I've never heard of PrimeVue, but they seem to have some paid offering, which I think is a red flag. All in all, the point of this issue was to migrate to components we own ourselves (like shadcn/ui), so that we don't have to rely on a big styled component library like VueBootstrap/PrimeVue/NuxtUI, instead building our own components (copying from shadcn) with Radix. |
@ErikBjare Woah, you are right that ShadcnUI is vendoring from Radix lol, but RadixVue, ShadcnUI, NuxtUI, PrimeVue are all MIT licensed, I don't think ownership should be a concern at all, you could style on top of it. If ur referring to paid offerings at PrimeVue, I think it's premade blocks like full component dashboards, which is normal for any lib to make money to support their maintainence longterm. Why is it a red flag? Components should be easy to maintain and upgrade, whatever OSS lib supports it, use it. All are OSS based. If you want custom styling all aforementioned libraries support it, it's just a matter of preference and easing developer anxiety about maintenance and migration. |
The vendoring approach with Radix+Tailwind was the appeal for me.
Just a pattern I've noticed in the past with such setups. It could be fine, just didn't give a great impression.
We're in the current situation because we use VueBootstrap which went unmaintained. The idea behind this issue was to investigate if using shadcn could give us a migration path and help ensure this does not happen again by taking ownership of the base components. |
Vue-bootstrap is keeping us on Vue 2. There is a Vue-bootstrap version developed for Vue 3, but it is taking forever to mature.
I've been using shadcn in a project recently and found it a very sensible approach.
Nice that it gives us control over style and implementation while making the markup standards compliant.
Shadcn for Vue exists here: https://www.shadcn-vue.com/
The text was updated successfully, but these errors were encountered: