episodes/is-shadcn-any-good

[utterances-bot]

Runtime Rundown

https://runtimerundown.com/episodes/is-shadcn-any-good

[danieluhl]

Usually I’m just nodding along the entire episode so it was good to finally feel differently. This whole episode felt a bit off to me, like y’all haven’t used tailwind in a big project on a regular basis. To me shadcn is an expansion of the tailwind philosophy so it’s both refreshing and familiar to use. I see the point of cva as not to solve a huge technical problem but to settle the debate and provide consistency. I’ve seen variants implemented in so many ways. It will be interesting to see how I feel a year or two from now but I’m loving this trend at the moment.

[helloitsjoe]

I'm glad to hear you disagree! shadcn is so popular right now and Tailwind can be divisive so I'm not surprised to hear our opinions don't resonate with everybody. I also think you're in the target demographic for shadcn, someone with a lot of familiarity with the dependencies (react-table, date-fns, etc), and familiarity with maintaining a design system.

like y’all haven’t used tailwind in a big project on a regular basis

This is absolutely the case, and I hope that came across in the episode. I'd love to hear specifically what you've liked about Tailwind and shadcn! Do you share any of the concerns we raised about future dependency upgrades?

[danieluhl]

Whoa, I didn't realize this shows up as a github issue. Neat!

You have good and valid points about dependency changes. I've been using shadcn for only a month and I like you mentioned I don't think anyone knows what the upgrade process will be like.

That said I think it's a problem we should tackle head on because the philosophy of shadcn solves a unique problem and the underlying philosophy I'd argue is the same as tailwind: I want speed and consistency, but I need it to be uniquely my branding and design. This is very appealing and adobe aria and aceternity have since followed suit.

Other design systems don't let you be you and writing from scratch sucks. I wrote something very similar to tailwind in 2015 but every time I switch projects I don't want to re-invent it and ramp everyone else up on it so I was thrilled when tailwind gained widespread adoption.

I'm really curious about what happened with @Cooperbuilt and tailwind. There are tradeoffs and I can imagine situations where it's not the best choice, but if I had the choice from a coding style/philosophy point of view, I'd pick it in a heartbeat. Maybe I need to seek out more commentary from the other side. Please share if you know any good articles bashing tailwind 🙂

[Cooperbuilt]

@danieluhl we use utterances for this so we get a GitHub issue per episode and on the suggestions page - so far it's been a good system to keeping out spam.

On to shad. I've reflected since our episode. I could see a real benefit to shad for agencies and other factory verticals where you need design systems frequently, but they need to be tailored. I can also see it being a big win for small companies that can't afford a design system team. The dependency management side of things is worrying though. It's definitely something we face now with other design systems, but the industry has built a lot of tooling around solving that problem (we have npm, dependabot, renovate). For shad, it's outside of even the npm world and into something entirely different. I'd wager they, or someone in the community, will eventually build something to make this easier but it's not a guarantee. This is made less of a guarantee because the shad update problem is local to shad, where general dependency update problems are global. As such, many more developers were brought to bear to solve them.

On to tailwind. A pound of salt is necessary here. I used this for a decent sized side project (more than 50ish components in a data driven sass application). In the beginning I had some fun with it. Over time, I found myself reaching more and more for the docs to figure out how to accomplish things I knew how to do in vanilla css. This friction frustrated me enough that I escaped out into vanilla css and continued writing that. Another thing - there's just a mental barrier for me with styles in my jsx/tsx. Especially when typescript is involved, adding tailwind felt like the ratio of signal to noise in my components went upside down. Coming back to a file with both typescript and tailwind made the file extremely noisy to re-read and grok. I know this is an older mindset born of "separation of concerns" in the old web, but I think there is still merit to it.

[hamlim]

[!WARNING] This is pretty rant-y since I'm writing this while listening to the episode in 2x, so it might not be well formed :joy:

I think the core value prop (or more so "founding principle") for shadcn/ui is that web developers have always needed to maintain their dependencies, and it's only trying to make that more clear to us.

Dependency management is a pain in the ass butt, but because it's named explicitly, no one (from what I've seen at least) considers it as part of the regular software maintenance that we need to do. Tools have made it easier to manage, but you still are on the hook for dependencies that you use to solve your business needs. Even though we have tools to help keep them up to date, and even upgrade automatically (in some cases), we trade that off for ease of customizing.

You can't easily patch <your-favorite-bundled-component-library> to customize it for some specific use case for example, but you can do that more easily with shadcn/ui.

However, there are always trade offs, with shadcn you're trading off ease of upgrades for ease of customization.

Longer term - I think codemods (e.g. Grit, or even AI assisted codemods) will help ease the upgrade process and offer a nice middle ground for managing code that's "inlined" as opposed to managed via a dependency manager.