Don't use Tailwind for a design system (2021)
1–10 of 164 posts
Re: Don't use Tailwind for a design system (2021)
#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 details.
Re: Don't use Tailwind for a design system (2021)
#3I've been using Tailwind for my component library and I don't agree.
For example "It is optimised for writing, but not for reading" is certainly a problem, but this is why I created a component library. To abstract this.
Also this is weird:
``` const Card = (props) => { const className = "p-" + props.gap.toString(); return ; }; ```
Why do this? If gap needs to be set, then break apart the Card subcomponents (Card.Title, Card.Description, Card.Footer) and let the consumer handle their odd logic that break the design system guidelines.
I have faced issues with Tailwind too, but I would pick this 10 out of 10 times over styled-components and such.
Re: Don't use Tailwind for a design system (2021)
#4> Tailwind isn't component-driven, which they claim to be
They don't ever claim to be component-driven. They are utility-class library and nothing else.
I highly recommend using twin.macro if you are using React. It basically combines tailwind with styled components and helps immensely with readability:
Re: Don't use Tailwind for a design system (2021)
#5I'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)];
...
These days I recommend learning CSS really well and then using Vanilla Extract (https://vanilla-extract.style), a CSS in TypeScript library that compiles down to raw CSS, basically using TS as your preprocessor instead of SCSS. For dynamic styles, they have an optional small runtime.
They have a Stitches-like API called Recipes that's phenomenal as well, especially for design systems, you can define your variants and what CSS needs to be applied for each one, so you can map your design components 1-to-1 with your code:
import { recipe } from '@vanilla-extract/recipes';
export const button = recipe({ base: { borderRadius: 6 },
variants: {
color: {
neutral: { background: 'whitesmoke' },
brand: { background: 'blueviolet' },
accent: { background: 'slateblue' }
},
size: {
small: { padding: 12 },
medium: { padding: 16 },
large: { padding: 24 }
},
rounded: {
true: { borderRadius: 999 }
}
},
// Applied when multiple variants are set at once
compoundVariants: [
{
variants: {
color: 'neutral',
size: 'large'
},
style: {
background: 'ghostwhite'
}
}
],
defaultVariants: {
color: 'accent',
size: 'medium'
}Impressive that OP still is using ReasonReact, I thought it was all but dead after ReScript.
Re: Don't use Tailwind for a design system (2021)
#6The 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 - Tailwind is hard to change compared to…Bootstrap? Foundation? BEM? MUI? It’s vastly, vastly easier to change Tailwind code than any of those frameworks (IMO).
I’m a Tailwind champion not because it’s the perfect solution, but because I’ve found it to be better overall than anything that came before it.
Re: Don't use Tailwind for a design system (2021)
#7I've been using Tailwind for my component library and I don't agree. For example "It is optimised for writing, but not for reading" is certainly a problem, but this is why I created a component library. To abstract this. Also this is weird: ``` const Card = (props) => { const className = "p-" + props.gap.toString(); return ; }; ``` Why do this? If gap needs to be set, then break apart the Card subcomponents (Card.Tit…
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.
Re: Don't use Tailwind for a design system (2021)
#8The guy is not happy because he still has to write CSS from time to time, yet says the classes from a CSS utility library, which prevent him from having to write too much CSS, should be thrown to garbage. Another absolute title article to make you click.
Re: Don't use Tailwind for a design system (2021)
#9I've been using Tailwind for my component library and I don't agree. For example "It is optimised for writing, but not for reading" is certainly a problem, but this is why I created a component library. To abstract this. Also this is weird: ``` const Card = (props) => { const className = "p-" + props.gap.toString(); return ; }; ``` Why do this? If gap needs to be set, then break apart the Card subcomponents (Card.Tit…
I would like some kind of editor plugin that would collapse all classNames by default. That would help a lot with Tailwind readability.
Re: Don't use Tailwind for a design system (2021)
#10I'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…
[flagged]