5 ms·

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

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 <SidebarItem /> is easier to read then <div class="flex-1 bg-blue font-bold, text-md d:none"></div> but nobody writes React like that. Everyone will have a SidebarItem component that spits out that div.

firemelt 4y ago
that is javascript programmer they think everyone write javascript
zmxz 4y ago
This was the reply I was looking for. Thank you. I don't know the purpose of misleading title, I guess this is how web works now - capture attention by misleading readers, then criticize the actual layer that causes problems, but hide the fact that the one in chair is at fault for not being a capable user of technology.
Jenk 4y ago
I'm guilty of implementing <SideBarItem /> as export { SideBarItem = (<div class="flex-1 bg-blue font-bold, text-md d:none"></div>) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity
- deleted 4y ago
  [deleted]
- nerdywordy 4y ago
  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 <SideBarItem padding={4} active={true} /> 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.
- nextaccountic 4y ago
  It's not a bad thing. Or if it's a bad thing, I'm guilty too
- zdragnar 4y ago
  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.
- digitalsankhara 4y ago
  If I were to look at your code (or revisiting my own after some time) I'd know what <SideBarItem /> was likely for straight away. But I would need to construct the likely intent of the <div> version in my mind. Of course you could abstract those classes into one that provides semantics; <div class="side-bar-item"></div>
  - Jenk 4y ago
    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. :)
    - digitalsankhara 4y ago
      Ha! Understood now.
- sally_glance 4y ago
  IMO it's not a bad thing at all unless you have that exact div snippet copy-pasted to a thousand other files.
  - Jenk 4y ago
    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. :)
franciscop 4y ago
> "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.
- michaelteter 4y ago
  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".
  - robswc 4y ago
    As a full stack that is mostly backend, I like the way CSS frameworks allow me to not have to worry too much about design. I originally used CSS "properly" but I found that it was a chore/pain basically recreating these CSS frameworks over and over. It can get messy pretty fast but I find once you sorta get a handle on the frameworks, it becomes easy to parse as long as people aren't doing 10+ classes per element. I've found working without a CSS framework, people will tend to re-invent the wheel 100 times. i.e. I've seen "padded-box" and "box-with-padding" classes. I experience the worst of the worst tho, as I do a lot of refactoring work, so my take is a bit bias haha.
franky47 4y ago
I do write like that. Heck, even a mix of both: <SidebarItem marginRight={2} />, 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/ https://chakra-ui.com/
- adamscybot 4y ago
  Right, huge +1 for Chakra. Chakra is basically tailwind but built on react primitives. It feels lot cleaner, and solves most of the issues mentioned.
  - franky47 4y ago
    It's amazing for quick UI building. Note however that this API is brought by Styled System [1], which Chakra uses (and exposes), and adds the component library and other niceties on top. My only regret with Chakra is that it's a tad runtime-heavy, and it's not really adapted to static content. I'd love to see some sort of compiler that digests a React tree into rendered HTML + CSS, with minimal JS just for style interactions (is this what Svelte does?) [1] https://styled-system.com/ https://styled-system.com/
- _nhh 4y ago
  The whole point of a design system is not to have local overrides. In a design system. You specify variants of a component. Each one has its own combination of style defined by the design system. You do not set „Gap“ to 2. you would specify smth like „small“, „medium“ or „large“ as props. This is not a tailwind issue.
  - sieabahlpark 4y ago
    [dead]
  - wry_discontent 4y ago
    > The whole point of a design system is not to have local overrides. Are you unfamiliar with having-a-boss?
redbar0n 4y ago
> 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 https://tailwindcss.com/#component-driven (scroll down to "Not into component frameworks?")

firemelt 4y ago

that is javascript programmer they think everyone write javascript

zmxz 4y ago

This was the reply I was looking for. Thank you. I don't know the purpose of misleading title, I guess this is how web works now - capture attention by misleading readers, then criticize the actual layer that causes problems, but hide the fact that the one in chair is at fault for not being a capable user of technology.

Jenk 4y ago

I'm guilty of implementing <SideBarItem /> as export { SideBarItem = (<div class="flex-1 bg-blue font-bold, text-md d:none"></div>) } Is that a bad thing? (Genuinely asking for opinions) E: added clarity

deleted 4y ago
[deleted]
nerdywordy 4y ago
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 <SideBarItem padding={4} active={true} /> 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.
nextaccountic 4y ago
It's not a bad thing. Or if it's a bad thing, I'm guilty too
zdragnar 4y ago
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.
digitalsankhara 4y ago
If I were to look at your code (or revisiting my own after some time) I'd know what <SideBarItem /> was likely for straight away. But I would need to construct the likely intent of the <div> version in my mind. Of course you could abstract those classes into one that provides semantics; <div class="side-bar-item"></div>
- Jenk 4y ago
  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. :)
  - digitalsankhara 4y ago
    Ha! Understood now.
sally_glance 4y ago
IMO it's not a bad thing at all unless you have that exact div snippet copy-pasted to a thousand other files.
- Jenk 4y ago
  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. :)

franciscop 4y ago

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

michaelteter 4y ago
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".
- robswc 4y ago
  As a full stack that is mostly backend, I like the way CSS frameworks allow me to not have to worry too much about design. I originally used CSS "properly" but I found that it was a chore/pain basically recreating these CSS frameworks over and over. It can get messy pretty fast but I find once you sorta get a handle on the frameworks, it becomes easy to parse as long as people aren't doing 10+ classes per element. I've found working without a CSS framework, people will tend to re-invent the wheel 100 times. i.e. I've seen "padded-box" and "box-with-padding" classes. I experience the worst of the worst tho, as I do a lot of refactoring work, so my take is a bit bias haha.

franky47 4y ago

I do write like that. Heck, even a mix of both: <SidebarItem marginRight={2} />, 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/ https://chakra-ui.com/

adamscybot 4y ago
Right, huge +1 for Chakra. Chakra is basically tailwind but built on react primitives. It feels lot cleaner, and solves most of the issues mentioned.
- franky47 4y ago
  It's amazing for quick UI building. Note however that this API is brought by Styled System [1], which Chakra uses (and exposes), and adds the component library and other niceties on top. My only regret with Chakra is that it's a tad runtime-heavy, and it's not really adapted to static content. I'd love to see some sort of compiler that digests a React tree into rendered HTML + CSS, with minimal JS just for style interactions (is this what Svelte does?) [1] https://styled-system.com/ https://styled-system.com/
_nhh 4y ago
The whole point of a design system is not to have local overrides. In a design system. You specify variants of a component. Each one has its own combination of style defined by the design system. You do not set „Gap“ to 2. you would specify smth like „small“, „medium“ or „large“ as props. This is not a tailwind issue.
- sieabahlpark 4y ago
  [dead]
- wry_discontent 4y ago
  > The whole point of a design system is not to have local overrides. Are you unfamiliar with having-a-boss?

redbar0n 4y ago

> 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 https://tailwindcss.com/#component-driven (scroll down to "Not into component frameworks?")