Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sancho.dev

Post reply on HN
Print view View original

151–160 of 164 posts

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

#151

Post by sieabahlpark »

_nhh wrote: post #147
franky47 wrote: post #106

Earlier quoted context omitted.

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/

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.

[dead]

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

#152

Post by wry_discontent »

_nhh wrote: post #147
franky47 wrote: post #106

Earlier quoted context omitted.

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/

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.

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

Are you unfamiliar with having-a-boss?

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

#153

Post by manxman »

sergiotapia wrote: post #95
manxman wrote: 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…

There's an ideal and there's reality. In reality, CSS always ended up spaghetti and horrible to maintain. Even with BEM and other proposed solutions. Human nature and all that.

I'm not advocating for vanilla CSS and I agree BEM isn't really a solution.

But CSS in JS, SCSS/SASS etc. take the things that work about CSS and add variables etc. to give you something that's useful in the modern world while also giving you a way to keep things maintainable.

I worry Tailwind is kind of like the 'fast food' for styling. Tastes good in the moment and satisfies the need for quick calories but ain't gonna be healthy in the long term especially if you do too much of it.

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

#154

Post by marcosdumay »

wry_discontent wrote: post #152
_nhh wrote: post #147

Earlier quoted context omitted.

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.

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

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

#155

Post by marcosdumay »

manxman wrote: 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…

Well, yeah, the entire point of Tailwind is to not use CSS like it was supposed to be used.

Some people like this better. It reminds me of people that used to adjust the format of every single text area on Word instead of using styles. And on some contexts, that's even objectively better.

But most of the time it's just a bunch of developers arguing against generalization and encapsulation. I don't understand it either.

Anyway, just to add a bit:

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

Nowadays CSS has variables support that you can use for that.

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

#156

Post by nwienert »

dmitriid wrote: post #146
nwienert wrote: post #82

Earlier quoted context omitted.

That example doesn't use shorthands to be more clear, and shows the styled utility function which is a more advanced case of wanting to define a group of styles nicely. Which is incidentally fixing a couple of the problems in TFA. If you just want the simple Tailwind experience you can use shorthands only in those, or even closer just import or directly and use shorthands with typed tokens. It's there in a few of the…

My hunch is that the author of the article wouldn't like these shortcuts either :)

He proposed exactly them as the solution!

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

#157

Post by franky47 »

_nhh wrote: post #147
franky47 wrote: post #106

Earlier quoted context omitted.

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/

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.

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

#158

Post by akvadrako »

satvikpendem wrote: post #5

I've used Tailwind extensively at previous companies and inevitably each one creates an abstraction that's akin to: const headerClasses = [(list of Tailwind classes here)]; ... because the complexity of reading and writing all of the classes is just too much. At that point, you've just reinvented CSS classes. Tailwind fans will tell you to not do this but if multiple companies are independently having the same proble…

Attributify mostly solves readability issue:
https://windicss.org/features/attributify.html

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

#159

Post by di4na »

presentation wrote: post #109
di4na wrote: post #59

Earlier quoted context omitted.

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.

I get you, the problem is that CSS in JS is simply not possible for the vast majority of web developers out there that work on a site render framework that is not JS ;)

I think this is the main reason why Tailwind took off so fast. The frontend tooling world forgot the majority of its users.

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

#160

Post by iamsaitam »

hnbad wrote: post #34
dimitrisnl wrote: post #3

I've been using Tailwind for my component library and I don't agree. For example "It is optimised for writing, but not for reading" is certainly a problem, but this is why I created a component library. To abstract this. Also this is weird: ``` const Card = (props) => { const className = "p-" + props.gap.toString(); return ; }; ``` Why do this? If gap needs to be set, then break apart the Card subcomponents (Card.Tit…

FWIW this code would also break with newer versions of Tailwind as it tries to generate a Tailwind class name on the fly. Tailwind needs all class names to be statically analyzable (via very dumb pattern matching) to pare down the infinite list of possible class names to something you can actually write to a CSS file for production. On a related note, the article's example of why Tailwind is clumsier for a Box compon…

You can provide a whitelist of classes you use dynamically in the config file.
Post reply on HN