Earlier 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.
Don't use Tailwind for a design system (2021)
101–110 of 164 posts
Re: Don't use Tailwind for a design system (2021)
#102This 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…
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.
Re: Don't use Tailwind for a design system (2021)
#103This 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…
I'm guilty of implementing as export { SideBarItem = ( ) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity
It's how (nearly) everyone using React (or any frontend framework) + Tailwind will structure their code. And I'm not sure the author is arguing against Tailwind's utility in static styling scenarios.
I think the article's author would argue that once you move beyond static classes that Tailwind's class building becomes messy.
So would be cleaner in the authors mind if the exposed props get applied by some other tooling better suited for dynamic styling instead of simple string manipulation.
There is some merit to that argument. Building the class string can be cumbersome in some scenarios. But Tailwind "clicks" for me where other solutions do not. So I do it anyways.
Re: Don't use Tailwind for a design system (2021)
#104Is 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…
tbh, tailwind feels like the worst thing that happened to frontend dev since coffee script.
Re: Don't use Tailwind for a design system (2021)
#105This 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…
I'm guilty of implementing as export { SideBarItem = ( ) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity
Or if it's a bad thing, I'm guilty too
Re: Don't use Tailwind for a design system (2021)
#106This 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…
Even the best design system needs local overrides to satisfy a product owner's incomprehensible requests, like "can we push that button a few pixels to the left?".
Re: Don't use Tailwind for a design system (2021)
#107This 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…
I'm guilty of implementing as export { SideBarItem = ( ) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity
YMMV; I prefer styled/ emotion-styled for primary, reusable blocks, and tailwind for one-off exceptions like a bit of extra margin.
Re: Don't use Tailwind for a design system (2021)
#108This 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…
I'm guilty of implementing as export { SideBarItem = ( ) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity
Re: Don't use Tailwind for a design system (2021)
#109Earlier quoted context omitted.
I believe the solution here is most definitely @apply. I know the Tailwind team seem to be against @apply (and even flirted with removing it), but having used it extensively to build complex (imo) sites and apps, @apply has been unavoidable and actually great to have. The fact is @apply is there and if we're using it and there's enough push-back, I don't see why the Tailwind team wouldn't listen to that or create a w…
The real answer is in CSS developing a proper supported way to do mixins. I keep being surprised that noone bring this up in these discussions.
Re: Don't use Tailwind for a design system (2021)
#110This 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…
I'm guilty of implementing as export { SideBarItem = ( ) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity