Hacker News Reader

Comment by dubcanada | Hacker News Reader

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.

View on HN

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/

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.

`2` in this case is a design token that is defined in a theme, that would resolve to a length defined in a CSS unit (ideally rem).

How would you handle a design change where a size becomes required that fits between "small" and "medium"? These things happen throughout the lifetime of a project.

Opaque numerical design tokens may not be the most explicit to understand, but they allow for expansion.

> The whole point of a design system is not to have local overrides.

Are you unfamiliar with having-a-boss?

He is familiar with the boss being the one mandating the design system, and not the one asking "can we push that button a few pixels to the left?"

On the places where things work, bosses act like the GP's one. Granted, that doesn't happen on the large majority of places.

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.

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/

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.

I'm guilty of implementing

    <SideBarItem />

    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

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.

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.

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;

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. :)

Ha! Understood now.

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. :)

It's not a bad thing.

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

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

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.

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

that is javascript programmer they think everyone write javascript

Reply on news.ycombinator.com