Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sancho.dev

Post reply on HN
Print view View original

41–50 of 164 posts

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

#41

Post by nwienert »

redbar0n wrote: post #28
danielvaughn wrote: post #6

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.

Tamagui actually does solve all four of the mentioned problems in the article.

One nice thing is that it does so in a way that allows for avoiding doubling the depth of your component tree by having to do HOC type solutions as many seem to do to work around them.

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

#45

Post by nwienert »

pcthrowaway wrote: post #27
satvikpendem wrote: post #5

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…

Tamagui really aims to solve this problem and some of the usability problems of className by putting style props directly on the props. You can nest components and abstract them as you want and still get the Tailwind style shorthands except as TS typed tokens.

No worry about how you reference things or static-ness etc and the final output can be flattened down to just div + css even across module boundaries or when nesting multiple times.

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

#46

Post by antihero »

satvikpendem wrote: post #12
b93rn wrote: post #10

Earlier quoted context omitted.

[flagged]

No, I haven't. As I said I've worked in several companies that explicitly have this sort of abstraction. If so, what's the point of using Tailwind? Tailwind fans will say it's atomic classes, but when using them with many devs, it indeed turns into reinventing CSS classes. So, perhaps it's the other way around, that Tailwind is simply not a good tool at scale.

Tailwind shines when paired with a component based library such as react. If you’re repeating the classes all the time, perhaps create a component for that.

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

#47

Post by satvikpendem »

piaste wrote: post #35
satvikpendem wrote: post #12

Earlier quoted context omitted.

No, I haven't. As I said I've worked in several companies that explicitly have this sort of abstraction. If so, what's the point of using Tailwind? Tailwind fans will say it's atomic classes, but when using them with many devs, it indeed turns into reinventing CSS classes. So, perhaps it's the other way around, that Tailwind is simply not a good tool at scale.

As I understand it, Tailwind is essentially CSS 2.0 - or 5.0 I guess - with the warts ironed out (sorry for the unpleasant mixed metaphor): A) CSS / Tailwind: lots of little 'atomic' classes describing individual visual properties. Easy to understand, easy to customize, but slow to read, slow to get started, with plenty of stuff to learn B) CSS frameworks / Tailwind-based components: fewer classes declaratively descr…

CSS is fine, arguably even good these days. For every new feature in CSS, such as the is, has, not selectors, Tailwind needs to reimplement them in its own way, basically becoming a DSL in the process.

I mean, look at the syntax for something like this:

    [--scroll-offset:56px] lg:[--scroll-offset:44px]

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

#48

Post by satvikpendem »

antihero wrote: post #46
satvikpendem wrote: post #12

Earlier quoted context omitted.

No, I haven't. As I said I've worked in several companies that explicitly have this sort of abstraction. If so, what's the point of using Tailwind? Tailwind fans will say it's atomic classes, but when using them with many devs, it indeed turns into reinventing CSS classes. So, perhaps it's the other way around, that Tailwind is simply not a good tool at scale.

Tailwind shines when paired with a component based library such as react. If you’re repeating the classes all the time, perhaps create a component for that.

My example was within components. Even inside components it's just visual clutter, hence the abstraction I mentioned.

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

#50

Post by lazy_moderator1 »

satvikpendem wrote: post #5

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…

all kinds of companies make bad choices, i've also seen a bunch of companies use tailwind correctly -> components + @apply are enough to make it very pleasant to work with :)
Post reply on HN