Live data from Hacker News

Don't use Tailwind for a design system (2021)

sancho.dev

21–30 of 164 posts

Re: Don't use Tailwind for a design system (2021)

#21
I have to chuckle a little at these posts that seem to be 'upset' that Tailwind (or some new framework du jour) is not the silver bullet that the hype train has had them believe

I love Tailwind and use it daily, have done for almost 6 years now and I haven't experienced any issue I couldn't solve

It certainly has never got me thinking to just throw it away or denigrate it publicly. And my solutions have worked well in a team setting - not adding any burden to other devs

This feels more like it's at the intersection of React-specific problems and lack of experience with Tailwind and/or CSS in general

I can see some of these problems being frustrating, but because the author seems to just be sounding off without much effort to express attempted solutions, I'm flagging because I feel like this is just anti-Tailwind inflammatory BS

Edit: Title also needs to indicate this is from 2021

Re: Don't use Tailwind for a design system (2021)

#23
post #2

> @apply is the directive that Tailwind recommend to extract repeated utility patterns. Since it's a static definition, you would only abstract those lists into a CSS file. I don't want to get into much details about it, but it does not solve the problems mentioned before. I would like to know why @apply does not solve the issues in the author's opinion. This is exactly the part where the author should have gone into…

[deleted]

Re: Don't use Tailwind for a design system (2021)

#24

Earlier quoted context omitted.

Concatenating Tailwind classes is a huge code smell. While you can safe list them, I've personally never done anything where I felt that it was worth the effort compared to just listing all possible classes.

I like to use a library called classnames. It lets you define dynamically-applied classes in a much more readable way. https://www.npmjs.com/package/classnames

Another (smaller) alternative is clsx: https://www.npmjs.com/package/clsx

Re: Don't use Tailwind for a design system (2021)

#25
post #2

> @apply is the directive that Tailwind recommend to extract repeated utility patterns. Since it's a static definition, you would only abstract those lists into a CSS file. I don't want to get into much details about it, but it does not solve the problems mentioned before. I would like to know why @apply does not solve the issues in the author's opinion. This is exactly the part where the author should have gone into…

Probably the same as this reasoning:

> Even that this snapshot of code-UI is doable in Tailwind, at some level of those components you will find a layer with a bunch of classNames that you need to parse in your head in order to imagine the UI.

So he would probably say that @apply just abstracts away the problem but it still exists somewhere that you'd need to parse through to understand the styling.

But this doesn't resonate with me. This isn't avoidable in any scenario. Either you have a styled component with a bunch of css-in-js, or a bunch of css, or a bunch of utility classes. In all scenarios there is an implementation that you have to parse. Which basically means it has nothing to do with @apply and everything to do with css vs. utility classes.

Re: Don't use Tailwind for a design system (2021)

#26

I have to chuckle a little at these posts that seem to be 'upset' that Tailwind (or some new framework du jour) is not the silver bullet that the hype train has had them believe I love Tailwind and use it daily, have done for almost 6 years now and I haven't experienced any issue I couldn't solve It certainly has never got me thinking to just throw it away or denigrate it publicly. And my solutions have worked well i…

> but because the author seems to just be sounding off without much effort to express attempted solutions, I'm flagging because I feel like this is just anti-Tailwind inflammatory BS

On attempted solutions, there was a subsection titled: "What should I use instead of Tailwind for my design system?"

He also suggested this solution for Tailwind, if you read it carefully: "If you still like what Tailwind offers, I recommend a similar approach that we do at Draftbit. Create a tiny layer on top of it: Treat all the Tailwind tokens as code and maintain Tailwind scoped inside those components. Abstract those utility components that you found repeated in your code into a more strict version, and minimise Tailwind for your app."

The post was arguably not inflammatory, but pointed to specific issues with Tailwind viz-a-viz design systems. The points raised may not be correct(?), but that doesn't mean it's inflammatory BS.

> Edit: Title also needs to indicate this is from 2021

Good point. Updated.

Re: Don't use Tailwind for a design system (2021)

#27

I've used Tailwind extensively at previous companies and inevitably each one creates an abstraction that's akin to: const headerClasses = [(list of Tailwind classes here)]; ... because the complexity of reading and writing all of the classes is just too much. At that point, you've just reinvented CSS classes. Tailwind fans will tell you to not do this but if multiple companies are independently having the same proble…

I actually agree with this criticism, and it's the best criticism of Tailwind I've seen so far.

I still love using it, and will continue to do so. This isn't enough to stop me from using it. Normally I try to avoid this, and abstract the repeated bundle of tailwind classes in a component instead (it can be a container component or just some useful utility component to avoid having to repeat the same group of classes too much). This can have its own drawbacks, because having too many custom components that you need to remember to use in given situations (which is effectively how most design-systems would work anyway) makes the codebase less approachable.

And even still, we'll end up using the above trick (referencing a group of classes bundled into a property of an object somewhere else) from time to time, as well as the obvious option of just repeating classes as necessary. Referencing classes from an imported object is annoying too, because it breaks intellisense.

I'm honestly not sure what a better solution is though, because Tailwind has really sped things up for me compared to CSS/Sass/Chakra/Material.

Re: Don't use Tailwind for a design system (2021)

#28

The author makes a couple of valid points, although these aren’t reasons to not use Tailwind. Rather, they’re just the trade-offs you have to sacrifice for the benefits that Tailwind provides. Whether the trade-offs are worth it depend on your use case and your professional opinion. That being said, when looking at Tailwinds problems, you have to ask yourself “compared to what?” Especially that first complaint - Tail…

> “compared to what?” Especially that first complaint - Tailwind is hard to change compared to…

The author compared it to Chakra UI (in the last code sample; misspelled Charkra).

He recommends ThemeUI, Rebass, Stitches and Radix for a design systems, specifically. A recent and very powerful alternative is Tamagui which takes inspiration from all of those.

Re: Don't use Tailwind for a design system (2021)

#29

I have to chuckle a little at these posts that seem to be 'upset' that Tailwind (or some new framework du jour) is not the silver bullet that the hype train has had them believe I love Tailwind and use it daily, have done for almost 6 years now and I haven't experienced any issue I couldn't solve It certainly has never got me thinking to just throw it away or denigrate it publicly. And my solutions have worked well i…

> but because the author seems to just be sounding off without much effort to express attempted solutions, I'm flagging because I feel like this is just anti-Tailwind inflammatory BS On attempted solutions, there was a subsection titled: "What should I use instead of Tailwind for my design system?" He also suggested this solution for Tailwind, if you read it carefully: "If you still like what Tailwind offers, I recom…

Updated.

You don't need the month, the HNconvention just uses the year in parens and some things rely on that format.

Re: Don't use Tailwind for a design system (2021)

#30

I have to chuckle a little at these posts that seem to be 'upset' that Tailwind (or some new framework du jour) is not the silver bullet that the hype train has had them believe I love Tailwind and use it daily, have done for almost 6 years now and I haven't experienced any issue I couldn't solve It certainly has never got me thinking to just throw it away or denigrate it publicly. And my solutions have worked well i…

[deleted]
Post reply on HN