Live data from Hacker News

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

sancho.dev

101–110 of 164 posts

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

#101
post #71
post #65

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.

You could do that but many of the minor stylings might not warrant a component, like a specific hover effect. For quick prototyping though it just is way more convenient to not to constantly break apart small html snippets into their own components.

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

#102

This 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.

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

#103
post #98

This 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

No, it's not a bad thing.

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)

#104
post #83
post #68

Is 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.

Arguably coffeescript was a big push to move JS spec forward into ES6 and beyond.

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

#105
post #98

This 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 not a bad thing.

Or if it's a bad thing, I'm guilty too

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

#106

This 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 do write like that. Heck, even a mix of both: , using Chakra-UI [1] (not too dissimilar to Tailwind in spirit).

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?".

[1] https://chakra-ui.com/

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

#107
post #98

This 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 lends itself to copy-pasting everywhere. Styles end up getting over-applied. Markup becomes 3x harder to scan because the signal: noise ratio is horribly skewed.

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)

#108
post #98

This 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

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;

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

#109
post #59

Earlier 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.

I do it with emotion (CSS in JS), specifically NOT using styled components and instead using the CSS prop which allows for composing styles more naturally, and it works great. Never felt a need to get my team on Tailwind since it’s already super productive with the right set of mixins.

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

#110
post #98

This 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

IMO it's not a bad thing at all unless you have that exact div snippet copy-pasted to a thousand other files.
Post reply on HN