[dead]
Don't use Tailwind for a design system (2021)
111–120 of 164 posts
Re: Don't use Tailwind for a design system (2021)
#112Earlier quoted context omitted.
> At that point, you've just reinvented CSS classes. Sort of, except instead of context switching between CSS, HTML, JS and your programming language, you can now remove the CSS entirely. Less context switching is good. I'm a Tailwind fan and I don't see a problem with that pattern for some cases. Obviously there are better ways to organize that should be preferred in general, but it's fine to do that here and there.
You still have to context switch between thinking about markup vs styling vs behaviour. The language you write the styling in barely makes a difference imo
Sure, but you don't have to switch between types of files, syntax, etc. "Barely makes a difference" seem subjective, so YMMV.
Re: Don't use Tailwind for a design system (2021)
#113Earlier quoted context omitted.
Yeah I don't understand what the other solution would be. If you want to have reusable styles, eg "btn" class with all your defaults @apply is the obvious choice. Otherwise you'll end up with similar gargantuan CSS class spagetti and/or have to abstract away some generic components because handling the classes is just too much.
I was under the impression that you create a button component and apply the atomic styles in that component. That way you don’t don’t need a “btn” class, you just use the Button component anywhere you need a button.
What if you need to render your button component as an anchor element? Or as a div with role="button"? You will want to abstract your button styles somehow so that they can be shared between these three (or more) use cases. Sure you could experiment with using a polymorphic `as` prop to render your button component as any element, but if you're using TypeScript that can get complicated quickly, especially if you're then trying to use that component in conjunction with something like next/link or react-router/link. It's simpler to strip default styles from all your components, and then have a button class to add to any element you want to appear as a button.
BUT, then what if you want to add some kind of special behavior to your button that involves subcomponents, e.g. a loading state that conditionally renders a spinner inside the button? Or you want to provide convenience props like rendering an icon before or after the button text? Then a class is not enough.
If you're building a design system/component library, none of these options are simple and there are always tradeoffs.
Re: Don't use Tailwind for a design system (2021)
#114This should be called "Don't use Tailwind in a React library for a design system" as this really has nothing to do with Tailwind and is all about integration of Tailwind into a React design system. None of these "negatives" are "negatives" for using it as part of a standard HTML/CSS website outside of React. The comparison between readability of a bunch of divs and web components or react makes no sense, of course is…
> "but nobody writes React like that" If it's "possible" people WILL write code like that. That's why I like styled-components, you are FORCED to separate the style definition and then you can say nobody writes code like that. But dozens of style classes mixed with functionality? People DO write code like that, a lot more than I like admitting seeing myself.
This is why I have a hard time getting on the Tailwind bandwagon. It feels like a pipeline equivalent to "margin: 1px 0 0 4px;" and other element-specific stylings _everywhere_.
CSS brought some opportunity for structure. At least it started out as "define a common style for a thing", and then if you really wanted to make a small deviation you could inherit and override something from the class.
Could be that since I'm not a frontender I just don't get it, but to me it feels like "global variables everywhere".
Re: Don't use Tailwind for a design system (2021)
#115Earlier quoted context omitted.
I'm guilty of implementing as export { SideBarItem = ( ) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity
IMO it's not a bad thing at all unless you have that exact div snippet copy-pasted to a thousand other files.
I meant SideBarItem's implementation is the tailwind div, but is referenced as SideBarItem like any other React component, not that the tailwind div is pasted all over. :)
Re: Don't use Tailwind for a design system (2021)
#116I'm going the opposite way and switching from CSS-in-JS to Tailwind.
While I like the css-in-js way of doing things, React seems to be moving away from runtime css generation, and I'm not sure the ecosystem will catch up (and I'm tired of playing catch up).
Sticking to CSS guarantees you won't have any compatibility problems.
Re: Don't use Tailwind for a design system (2021)
#117Earlier quoted context omitted.
I'm guilty of implementing as export { SideBarItem = ( ) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity
If I were to look at your code (or revisiting my own after some time) I'd know what was likely for straight away. But I would need to construct the likely intent of the version in my mind. Of course you could abstract those classes into one that provides semantics;
I meant SideBarItem's implementation is the tailwind div, but is referenced as SideBarItem like any other React component, not that the tailwind div is pasted all over. :)
Re: Don't use Tailwind for a design system (2021)
#118Is it just me or has the underlying purpose and value of “cascading” in CSS been lost within these abstractions. The only real limitations with CSS imho was just lack of variable support for easily passing in variables to set color schemes and/or dimensions etc. These seemed to be readily fixed with SCSS and the various options for embedding CSS in JS using styled components and the like. Tailwind seems to be all abo…
Out of curiosity, have you used Tailwind and does your criticism come from having used it and not experiencing the progress or does your criticism come from reading how it works and not "feeling" it? I don't intend to follow up with discussion that convinces/dissuades/criticizes you in any way, I just ask purely out of curiosity.
I had the chance to use Tailwind recently. I don’t think it’s disputable that in a sense it mocks the “cascading” part of CSS, though I’m not sure I’d hold that against Tailwind. It often felt as taking a shortcut to me, but it could be a worthy tradeoff and so far I have not noticed Tailwind overly complicating maintenance and development of an average project. That said, I don’t think I would choose Tailwind if I could use, e.g., web components with scoped styles or something similarly more in line with the spirit so to speak.
Re: Don't use Tailwind for a design system (2021)
#119This should be called "Don't use Tailwind in a React library for a design system" as this really has nothing to do with Tailwind and is all about integration of Tailwind into a React design system. None of these "negatives" are "negatives" for using it as part of a standard HTML/CSS website outside of React. The comparison between readability of a bunch of divs and web components or react makes no sense, of course is…
> This should be called "Don't use Tailwind in a React library for a design system"
That's true.
> as this really has nothing to do with Tailwind
Well.. it has to do with using Tailwind with React for a design system. :)
He does mention that @apply doesn't fix the problems he mentions, which is what Tailwind suggests as the solution for abstraction when you don't use a component framework: https://tailwindcss.com/#component-driven (scroll down to "Not into component frameworks?")
Re: Don't use Tailwind for a design system (2021)
#120Earlier quoted context omitted.
You still have to context switch between thinking about markup vs styling vs behaviour. The language you write the styling in barely makes a difference imo
Sure, but you don't have to switch between types of files, syntax, etc. "Barely makes a difference" seem subjective, so YMMV.
Tailwind classes are a syntax (especially since you can set arbitrary values e.g. `top-[-113px]`) and they still represent CSS. So really you're using a DSL with its own syntax, functions and directives on top of the CSS you should still understand. The main benefit is speed: you have a library of utility classes that are shorthand for common CSS patterns. If you are pretending that you're not writing CSS, you are forgetting how the browser is actually working -- eventually you may have to leave Tailwind and you'll find you've forgotten how to write good CSS.