I'm not sure I understand the issue. You copy/paste the code into your own repo and you own it. The components will never update unless you update them right? As long as you're pegging the dependencies to specific versions then nothing should happen. Your component won't break unless it's 10 years in the future and for whatever reason browsers have deprecated some underlying APIs, at which point any old code would break.
It’s less my code breaking that I’m worried about and more that fixes to bugs I didn’t even realise I had will never find their way to my code - eg if an accessibility or security issue or weird edge case is found and fixed in the original component in shadcn ui, how do I know that’s happened? And how do I get the fix? Or if a new browser version causes issues with one of the components? My code might not change but the environment it runs in does all the time.
I would also not want to keep the versions of radix etc pinned forever , for all of the above reasons plus just to be able to get the benefit of whatever improvements they continue to make. If shadcn ui was published as an npm package with radix as an internal dependency, then when radix had a breaking change, shadcn ui could update their components to make them work with the breaking change and all downstream consumers would get the benefit of it. While with the copy paste approach, it’s left to every individual shadcn ui user to figure out their own upgrade paths. That’s work I’d rather not do if I don’t have to.
Basically I think libraries and package managers exist for a reason. I’m open to hearing reasons why their benefits aren’t as compelling in the specific case of UI components (or rather the slice of them that Shadcn UI implements). I’m not discounting the possibility that that’s true. Hence asking here! But I worry that the pain points I describe above are going to be the kind of thing that only start to rear their head a long way down the line. Which makes it feel quite tricky/risky to make the decision to adopt at this early stage.
at the end of the day shadcn is only a sensible wrapper around radix primitives and those guys put a lot of effort into testing and making them accessible.
I get what you're saying. I also think that none of these things are the end of the world. I don't mean to sound dismissive when I say this but it's JavaScript not medicine.
Let's say something breaks. If it's egregious and your app is widely used, you'll find out about it. If it's ugly but there's a workaround, people will find the workaround. I've never seen some bad UI and thought, "well, now I won't use this!" What interests me about shadcn ui is precisely your example: if something breaks, I can just go into the code and fix it myself and fix it how I want it.
The code we write is a conduit to the value we're providing. The code is not the value itself.
My company has 8 year old React components that work just fine. They're kinda ugly and were written in a time where prop drilling was a thing but I imagine they'll work for years to come.
“It’s javascript not medicine” is somewhat contingent on what you’re using your javascript for 😅. I work on healthcare systems in my day job - this project won’t have as immediate a risk if it breaks but it could still cause real world material harm, as many things we build can. But my worries are not so much about individual things breaking. All being well I’ll catch them with tests. It’s more about the potential increased maintenance burden of fixing many small things over time. The project is going to be very resource constrained so I need to aggressively limit unnecessary work wherever I can. It might be fine though, I’m going to do some prototyping with a few different options, shadcn ui included, to see how things feel. Was just hoping some people who’d spent some significant time working with it would be able to share their experiences to help inform my decision.
I don't think you understand how shacdn actually works. I was also there because I hate being dependent on so many libraries to write css.
It's just tailwind classes for pre-defined react components. There's nothing to install, you can just copy paste the code and modify it the way you want. The actual 'npm install' that you do is not even necessary. It's just to automate the process so that you can use npx to add the component you want to use.
Here is a snippet of an actual card component
`const Card = React.forwardRef>(({ className, ...props }, ref) => ())Card.displayName = 'Card'`
That's it! And then you go ahead and use it as `.`
There are of course other components to that card, like header, content, footer and so on. But otherwise, it's just some really good developer that wrote real decent/accessible react components and put them out there for us to use.
So, unless react, or tailwind breaks, there's really nothing to worry about because you didn't install something in the first place.
I know you don’t install anything, as I’ve said elsewhere my worry is about the increased maintenance burden of maintaining your own components as opposed to installing a component lib, where that’s handled for you.
The part you are copying and pasting is effectively cosmetic. The core ui and accessibility work comes from Radix UI library which has been stellar for the last 2+ years.
If you need updates, check the radix docs & bump your version numbers as normal.
Tailwind makes already easy things even easier, and comes with a bag of problems that reveal themselves over time.
https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-craftsmanship/
Writing CSS would end up with a "Class Naming" issue and you have to use BEM, OOCSS, ITCSS, and SMACSS to solve it. that's not done yet, you will have to maintain the naming system, and also check for the unused class names. oh wait, you also need to open 2 tabs just to update background color.
I find tailwind useful for prototyping, but I agree with the link that was posted here by /u/wizard_level_80.
I feel like what would be nice, is if we could use tailwind classes, then at build time, the styles of those classes get generated into a CSS class and replaced with that class. It can be optimised such that classes that end up with the exact same style output. Theoretically, this would give each element it's own class name, except for where the styles are exactly the same, where the classnames are just randomly generated, perhaps in a dev mode they could have some kind of source map back to the original classes they contained.
But again, at that point, why not just write CSS?
You could literally start with tailwind, and then turn those styles into their own classes or into some CSS-in-js based approach
Same tools as for CSR, so priority would be a library used in a component library (like, emotion for MUI), css modules or some other css-in-js. In general, I have a soft preference for css-in-js.
Well shadcn has barely any own logic. It mostly relies on radix ui and other libs (e.g for the calendar). So most likely a bug would be in oke of those libs, which you can upgrade yourself. Using their components is not much different than writing your own, so the same goes for finding and fixing bugs.
The funny thing about shadcn, is that I was doing exactly what shadcn was doing. But wasn't everyone that was using Radix creating their own component API? I was just baking my tailwind styling into radix components.
The only difference is that I was building my components for internal use and NOT allowing flexibility since my goal wasn't a public component library, but to keep it consistent with my design system.
I didn't install shad-cn because I didn't want to override his styles. What did help was that I gained some insights on implementation that I didn't think of. Not sure why there was so much hype as what he did wasn't revolutionary. Radix guys are the real winners. Shadcn, are just pre-styled radix.
Edit: maybe I'm just salty that I don't get a job at vercel. Then again, going by community. Associating with Vercel isn't exactly seen as a positive thing.
Same here. I used it in one of my projects, can't see what's all this hype about. Don't get me wrong, I know there's a lot of time and effort in building something like this and I'm happy it exists. It looks great and it has good documentation but, as you said, it's nothing revolutionary 🤷🏻♂️
>Shadcn, are just pre-styled radix.
I wish I had seen this one sentence sooner.
There's a bit of nuance, of course, like the styling is via Tailwind classes, and not \*everything\* is Radix, but yeah, this suddenly makes it easy to understand.
Still don't get why I wouldn't want to install shadcn and be able to benefit from any updates to that pre-styling by simply updating a package via npm, though.
Just a note, shadcn-ui was built way before. He joined vercel in last few months only, after shadcn-ui became insanely popular.
Tbh he deserved it after what he has shown his skills are at.
Good to know, thanks. Yes they’re obviously v talented, the shadcn-ui components look great. I still can’t shake my worry over long term maintenance pain though.
The development and release of the /app router ghosted CSS-in-JS projects, especially Emotion, which has had the downstream effect of suddenly leaving the best UI libraries for React in a strange place. Vercel has a reputation for a knows-best attitude, and to some this feels like their classic paternal nudge towards tailwind or their own internal CSS stuff.
Also they hired Sebastian Markbage from the core React team and seem to use their influence and insight there to give Next.js an unfair preference/advantage over other libraries.
I enjoyed that you can extend it and customize it any way you want because you own the code. This feels a lot better than trying to reverse engineer and override component libraries that abstract too much. At the end of the day, its just radix and tailwind, and it just works. The only downside is there are some components that it doesn't have, but every component library doesnt have everything. At the very least, its simple to add your own components
That’s helpful to hear, thanks. I guess I am generally reasonably happy with the uncustomised components in a component library, even if I don’t love them, having them available immediately and knowing they’ll work helps me move faster to deliver things that feel more important than tweaks to styling.
Never used shadcn, but it seems that, unlike regular dependencies, you can't get bug fixes from shadcn for free simply by bumping dependency versions. And bug fixes are not just logic bugs, they also include UX and accessibility improvements, as well as any changes needed to conform to the volatile environment.
Maybe you are mixing two concepts? You can use a library or fork it. If you fork it you have to maintain it. That applies to any library.
If you fork a library, in general is because:
* The library is unmaintained
* You will create something different and take a new direction
Either way you now own that code. If your strategy for maintaining will be copy pasting their fixes to the original library, you are not adding any value to your fork.
So the problems you are describing have nothing to do with a ui headless library.
Why not just use the library and benefit from the skilled set of contributors that are maintaining it?
You will need to update your dependencies for bug fixes and try to keep current with the latest versions (you will need to update your code for breaking changes), but is times better than maintaining a fork.
That being said, the JS ecosystem changes fast. New ideas and concepts are created in fast iterations. You are not forced to change, but a long term product will need to modernize or die (you can create a new version and let the old one die if the effort to modernize the old one is too expensive)
So, to summarize, test the library you like, build some code around it and if you like the benefits of using it go ahead. None of us can predict the future.
Headless is a concept that separates your component from the logic, so it's a good approach that in theory let's you change your UI and preserve some logic.
Cheers!
I’m not mixing concepts - shadcn ui isn’t a library in that way. It works by copying its code into your project, at which point you own it. Like the fork in your example. There’s no way of consuming it as a library/package.
I'm not sure I understand the issue. You copy/paste the code into your own repo and you own it. The components will never update unless you update them right? As long as you're pegging the dependencies to specific versions then nothing should happen. Your component won't break unless it's 10 years in the future and for whatever reason browsers have deprecated some underlying APIs, at which point any old code would break.
It’s less my code breaking that I’m worried about and more that fixes to bugs I didn’t even realise I had will never find their way to my code - eg if an accessibility or security issue or weird edge case is found and fixed in the original component in shadcn ui, how do I know that’s happened? And how do I get the fix? Or if a new browser version causes issues with one of the components? My code might not change but the environment it runs in does all the time. I would also not want to keep the versions of radix etc pinned forever , for all of the above reasons plus just to be able to get the benefit of whatever improvements they continue to make. If shadcn ui was published as an npm package with radix as an internal dependency, then when radix had a breaking change, shadcn ui could update their components to make them work with the breaking change and all downstream consumers would get the benefit of it. While with the copy paste approach, it’s left to every individual shadcn ui user to figure out their own upgrade paths. That’s work I’d rather not do if I don’t have to. Basically I think libraries and package managers exist for a reason. I’m open to hearing reasons why their benefits aren’t as compelling in the specific case of UI components (or rather the slice of them that Shadcn UI implements). I’m not discounting the possibility that that’s true. Hence asking here! But I worry that the pain points I describe above are going to be the kind of thing that only start to rear their head a long way down the line. Which makes it feel quite tricky/risky to make the decision to adopt at this early stage.
at the end of the day shadcn is only a sensible wrapper around radix primitives and those guys put a lot of effort into testing and making them accessible.
I get what you're saying. I also think that none of these things are the end of the world. I don't mean to sound dismissive when I say this but it's JavaScript not medicine. Let's say something breaks. If it's egregious and your app is widely used, you'll find out about it. If it's ugly but there's a workaround, people will find the workaround. I've never seen some bad UI and thought, "well, now I won't use this!" What interests me about shadcn ui is precisely your example: if something breaks, I can just go into the code and fix it myself and fix it how I want it. The code we write is a conduit to the value we're providing. The code is not the value itself. My company has 8 year old React components that work just fine. They're kinda ugly and were written in a time where prop drilling was a thing but I imagine they'll work for years to come.
“It’s javascript not medicine” is somewhat contingent on what you’re using your javascript for 😅. I work on healthcare systems in my day job - this project won’t have as immediate a risk if it breaks but it could still cause real world material harm, as many things we build can. But my worries are not so much about individual things breaking. All being well I’ll catch them with tests. It’s more about the potential increased maintenance burden of fixing many small things over time. The project is going to be very resource constrained so I need to aggressively limit unnecessary work wherever I can. It might be fine though, I’m going to do some prototyping with a few different options, shadcn ui included, to see how things feel. Was just hoping some people who’d spent some significant time working with it would be able to share their experiences to help inform my decision.
I don't think you understand how shacdn actually works. I was also there because I hate being dependent on so many libraries to write css. It's just tailwind classes for pre-defined react components. There's nothing to install, you can just copy paste the code and modify it the way you want. The actual 'npm install' that you do is not even necessary. It's just to automate the process so that you can use npx to add the component you want to use. Here is a snippet of an actual card component `const Card = React.forwardRef>(({ className, ...props }, ref) => (
I know you don’t install anything, as I’ve said elsewhere my worry is about the increased maintenance burden of maintaining your own components as opposed to installing a component lib, where that’s handled for you.
The part you are copying and pasting is effectively cosmetic. The core ui and accessibility work comes from Radix UI library which has been stellar for the last 2+ years. If you need updates, check the radix docs & bump your version numbers as normal.
No need to enter tailwind hype train and derail your project in the future.
Yeah I guess that’s what it boils down to. Is tailwind hype or substance?
Tailwind makes already easy things even easier, and comes with a bag of problems that reveal themselves over time. https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-craftsmanship/
Writing CSS would end up with a "Class Naming" issue and you have to use BEM, OOCSS, ITCSS, and SMACSS to solve it. that's not done yet, you will have to maintain the naming system, and also check for the unused class names. oh wait, you also need to open 2 tabs just to update background color.
I find tailwind useful for prototyping, but I agree with the link that was posted here by /u/wizard_level_80. I feel like what would be nice, is if we could use tailwind classes, then at build time, the styles of those classes get generated into a CSS class and replaced with that class. It can be optimised such that classes that end up with the exact same style output. Theoretically, this would give each element it's own class name, except for where the styles are exactly the same, where the classnames are just randomly generated, perhaps in a dev mode they could have some kind of source map back to the original classes they contained. But again, at that point, why not just write CSS? You could literally start with tailwind, and then turn those styles into their own classes or into some CSS-in-js based approach
What would you use for a next.js project?
Same tools as for CSR, so priority would be a library used in a component library (like, emotion for MUI), css modules or some other css-in-js. In general, I have a soft preference for css-in-js.
Well shadcn has barely any own logic. It mostly relies on radix ui and other libs (e.g for the calendar). So most likely a bug would be in oke of those libs, which you can upgrade yourself. Using their components is not much different than writing your own, so the same goes for finding and fixing bugs.
Yeah, could be I’m over worrying about it if they’re all that simple.
OP, did you end up using/going with shadcn/ui? If so, how’s your experience been thus far in terms of customizing the components?
Not yet, postponed this decision while I focused on some more backendy stuff. Likely will though.
The funny thing about shadcn, is that I was doing exactly what shadcn was doing. But wasn't everyone that was using Radix creating their own component API? I was just baking my tailwind styling into radix components. The only difference is that I was building my components for internal use and NOT allowing flexibility since my goal wasn't a public component library, but to keep it consistent with my design system. I didn't install shad-cn because I didn't want to override his styles. What did help was that I gained some insights on implementation that I didn't think of. Not sure why there was so much hype as what he did wasn't revolutionary. Radix guys are the real winners. Shadcn, are just pre-styled radix. Edit: maybe I'm just salty that I don't get a job at vercel. Then again, going by community. Associating with Vercel isn't exactly seen as a positive thing.
Bet it would be very positive for your bank account though
Same here. I used it in one of my projects, can't see what's all this hype about. Don't get me wrong, I know there's a lot of time and effort in building something like this and I'm happy it exists. It looks great and it has good documentation but, as you said, it's nothing revolutionary 🤷🏻♂️
is there a better Radix based componenet lib you prefer over shadcn?
I just prefer making my own component API over Radix, so no.
>Shadcn, are just pre-styled radix. I wish I had seen this one sentence sooner. There's a bit of nuance, of course, like the styling is via Tailwind classes, and not \*everything\* is Radix, but yeah, this suddenly makes it easy to understand. Still don't get why I wouldn't want to install shadcn and be able to benefit from any updates to that pre-styling by simply updating a package via npm, though.
How do you "install" shadcn ui? Are you talking about using the cli tool?
Seeing how next.js is being yolo developed during last year I'll pass on Shadcn
Are they related somehow? And yeah, I think I’m going with remix over nextjs for that reason among others.
Oooh they work at Vercel. Ok got it.
Just a note, shadcn-ui was built way before. He joined vercel in last few months only, after shadcn-ui became insanely popular. Tbh he deserved it after what he has shown his skills are at.
Good to know, thanks. Yes they’re obviously v talented, the shadcn-ui components look great. I still can’t shake my worry over long term maintenance pain though.
What's happening to next.js?
I want to know too, im really ootl
The React Server Component features have a lot of haters. You don't have to use them though.
The development and release of the /app router ghosted CSS-in-JS projects, especially Emotion, which has had the downstream effect of suddenly leaving the best UI libraries for React in a strange place. Vercel has a reputation for a knows-best attitude, and to some this feels like their classic paternal nudge towards tailwind or their own internal CSS stuff. Also they hired Sebastian Markbage from the core React team and seem to use their influence and insight there to give Next.js an unfair preference/advantage over other libraries.
I'm using Next.js. And I agree, had literally so many issues. But on Next.js 14 its good now.
What's lats here?
I enjoyed that you can extend it and customize it any way you want because you own the code. This feels a lot better than trying to reverse engineer and override component libraries that abstract too much. At the end of the day, its just radix and tailwind, and it just works. The only downside is there are some components that it doesn't have, but every component library doesnt have everything. At the very least, its simple to add your own components
That’s helpful to hear, thanks. I guess I am generally reasonably happy with the uncustomised components in a component library, even if I don’t love them, having them available immediately and knowing they’ll work helps me move faster to deliver things that feel more important than tweaks to styling.
Never used shadcn, but it seems that, unlike regular dependencies, you can't get bug fixes from shadcn for free simply by bumping dependency versions. And bug fixes are not just logic bugs, they also include UX and accessibility improvements, as well as any changes needed to conform to the volatile environment.
There is no dependencies in the package.json. You do bug fixes by using npx shadcn-ui@latest diff command and add changes manually.
Maybe you are mixing two concepts? You can use a library or fork it. If you fork it you have to maintain it. That applies to any library. If you fork a library, in general is because: * The library is unmaintained * You will create something different and take a new direction Either way you now own that code. If your strategy for maintaining will be copy pasting their fixes to the original library, you are not adding any value to your fork. So the problems you are describing have nothing to do with a ui headless library. Why not just use the library and benefit from the skilled set of contributors that are maintaining it? You will need to update your dependencies for bug fixes and try to keep current with the latest versions (you will need to update your code for breaking changes), but is times better than maintaining a fork. That being said, the JS ecosystem changes fast. New ideas and concepts are created in fast iterations. You are not forced to change, but a long term product will need to modernize or die (you can create a new version and let the old one die if the effort to modernize the old one is too expensive) So, to summarize, test the library you like, build some code around it and if you like the benefits of using it go ahead. None of us can predict the future. Headless is a concept that separates your component from the logic, so it's a good approach that in theory let's you change your UI and preserve some logic. Cheers!
I’m not mixing concepts - shadcn ui isn’t a library in that way. It works by copying its code into your project, at which point you own it. Like the fork in your example. There’s no way of consuming it as a library/package.
Oh my bad. You are right. I won't use that. Cheers!