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

81–90 of 164 posts

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

#81

Post by redbar0n »

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…

> Is it just me or has the underlying purpose and value of “cascading” in CSS been lost within these abstractions.

I think you have a point. I think the cascading part was ignored for containment purposes during authoring, so it would scale and be predictable for larger teams. But ideally, I think we'd want to author using something like utility classes (or repeated style props?), but then compile them away to abstractions that cascade accordingly during runtime (least amount of kB sent over-the-wire as there would be as few as possible duplicated classes in the HTML, but also presuming that browsers using the cascade is more runtime performant than applying lots of atomic utility classes..?). Then we'd get abstractions without the cost of dealing with author-time abstractions (and having to name them). But then again.. there would then be a disconnect between what CSS classes you see when you author and what you see when you inspect the HTML/DOM... At least the utility classes are 1-to-1...

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

#82

Post by nwienert »

dmitriid wrote: post #76
nwienert wrote: post #41

Earlier quoted context omitted.

Tamagui actually does solve all four of the mentioned problems in the article. One nice thing is that it does so in a way that allows for avoiding doubling the depth of your component tree by having to do HOC type solutions as many seem to do to work around them.

> Tamagui actually does solve all four of the mentioned problems in the article. How? The very first example in Tamagui docs is this: export const Circle = styled(Stack, { backgroundColor: '$background', color: '$color9', borderRadius: 100_000_000, variants: { pin: { top: { position: 'absolute', top: 0, }, }, size: { '...size': (size, { tokens }) => { return { width: tokens.size[size] ?? size, height: tokens.size[siz…

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

The upside there is they are just regular props that are typed and have object de-structure and re-structure.

  import { Stack } from 'tamagui'

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

#83

Post by lyxsus »

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…

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)

#84

Post by dubcanada »

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 easier to read then but nobody writes React like that. Everyone will have a SidebarItem component that spits out that div.

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

#85

Post by jamager »

danielvaughn wrote: post #18
jamager wrote: post #16

Earlier quoted context omitted.

Agreed. For me an increasingly important factor is documentation. Good documentation can save so MUCH time and headaches, and tailwind's is so good that I have an easier time accepting its defects and trade-offs on that basis alone.

The tooling around Tailwind is so good. The VSCode intellisense plugin auto-suggests tailwind classes for me, which means I don’t even need to reference the docs unless I’m looking for obscure functionality. It’s amazing.

Yes!, Jetbrains works very well to.

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

#86

Post by seedboot »

dugmartin wrote: post #24
danielvaughn wrote: post #11

Earlier quoted context omitted.

I like to use a library called classnames. It lets you define dynamically-applied classes in a much more readable way. https://www.npmjs.com/package/classnames

Another (smaller) alternative is clsx: https://www.npmjs.com/package/clsx

Another (even smaller) alternative is `.join`

`const classes = [some, classNames, here, foo ? 'foo' : ''].join(' ');`

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

#87

Post by vehemenz »

satvikpendem wrote: post #12
b93rn wrote: post #10

Earlier quoted context omitted.

[flagged]

No, I haven't. As I said I've worked in several companies that explicitly have this sort of abstraction. If so, what's the point of using Tailwind? Tailwind fans will say it's atomic classes, but when using them with many devs, it indeed turns into reinventing CSS classes. So, perhaps it's the other way around, that Tailwind is simply not a good tool at scale.

I don’t understand. Do you think there is something in the CSS spec that dictates developers must use high-abstraction classes? What do you think CSS classes are?

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

#88

Post by lawn »

mvf4z7 wrote: post #71
tekkk wrote: 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.

This assumes you only have one button class, while you might want to reuse several that have minor differences.

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

#89

Post by redbar0n »

esskay wrote: post #22

Tailwind isn't component-driven, which they claim to be Stopped reading there. It's a utility library, that much has always been blatently clear and obvious. Really poor article.

FWIW here is the author's backing for that claim:

backing: https://twitter.com/davesnx/status/1329407408922370050

claim/thread: https://twitter.com/davesnx/status/1329392089189265408

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

#90

Post by zmxz »

dubcanada wrote: post #84

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…

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.

Post reply on HN