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

71–80 of 164 posts

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

#71

Post by mvf4z7 »

tekkk wrote: post #65
simonhamp wrote: post #33

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…

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.

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

#72

Post by abujazar »

blowski wrote: post #36
simonhamp wrote: post #33

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…

In general, framework owners _want_ you to become tightly coupled to the framework, whereas as a user you want to be able to move away from it more easily. I think this conflict of interests is behind recommendations like this, rather than sound technical reasons.

Why would framework owners want you to become tightly coupled to the framework? They're basically just offering a set of solutions that come with some tradeoffs, but they don't intentionally create problems for their users.

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

#73

Post by caseyf »

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…

I find that using utilities where appropriate is a win, not everything need be extracted into a stylesheet or component.

Having a standard library of utilities makes sense because if you don't use one you end up writing the exact same thin since they are mostly one liners.

What I don't understand is why you'd want to build a design system component out of utilities much less build everything out of utilities.

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

#74

Post by jkrubin »

HuwFulcher wrote: post #17

I don't use React or do much front-end work so I might be missing something here but what's the problem? Tailwind is a utility-first framework. If you're having to add so many classes inline that it makes things more difficult you can surely abstract it away within CSS files? I thought the main thrust of Tailwind is that you get a sensible set of utility classes so you can mix and match them how you need? For more co…

I am with you. I personally never have understood css to begin with. I like styled-components (et al (emotion and other css in js things)) because it makes distributing components with styles saner, but I really don’t do much front-end.

I am always blown away with what raw css can do and would like to learn it, but it doesn’t click for me. When I first heard about tailwind I thought it was awesome sounding as I don’t jive with css, but when I tried it I was dismayed to have YET ANOTHER build step and thing I had to screw with and configure outside of the src code.

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

#75

Post by gonzofish »

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…

I’ve liked the CUBE methodology since I first saw it. It takes all the ideas of these utility classes, but combines it with a BEM-lite approach to work with the cascade, not against it.

https://cube.fyi

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

#76

Post by dmitriid »

nwienert wrote: post #41
redbar0n wrote: post #28

Earlier quoted context omitted.

> “compared to what?” Especially that first complaint - Tailwind is hard to change compared to… The author compared it to Chakra UI (in the last code sample; misspelled Charkra). He recommends ThemeUI, Rebass, Stitches and Radix for a design systems, specifically. A recent and very powerful alternative is Tamagui which takes inspiration from all of those.

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[size] ?? size,
          }
        },
      },
    } as const,
  })
It's already worse than Tailwind. And the rest is just a bunch of predefined components that you can do with any library/framework/vanilla CSS.

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

#77

Post by caseyf »

gonzofish wrote: post #75
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…

I’ve liked the CUBE methodology since I first saw it. It takes all the ideas of these utility classes, but combines it with a BEM-lite approach to work with the cascade, not against it. https://cube.fyi

Yes! Use Tailwind for the "U"

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

#78

Post by dmitriid »

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.

For app-like websites CSS cascade offers little and is often harmful as an innocent change to a top layer will unpredictably cascade down to everything below.

> at the expense of having consistency and maintainability.

Compared to what. Every single website devolves into a nightmare of incomprehensible class names, or one-off CSS-in-JS solutions everywhere.

Compared to that the actually consistent names enforced by Tailwind are both consistent and maintainable.

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

#79

Post by vehemenz »

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…

Tailwind is much, much faster than building your own stylesheets with deeper abstractions.

In most cases, it is faster to use Tailwind than customizing an existing UI framework.

SCSS and CSS in JS are more complex solutions than Tailwind.

Maintainability is generally better with Tailwind because you don’t need to remember all of your abstractions and any hidden structures, eg this div.className always needs to be nested a certain way. Onboarding is trivial because Tailwind can be mastered in two afternoons.

Tailwind might not be for everyone, but the features it provides allow for rapid development and easy maintenance. The author has issues with Tailwind in React, but these seem mire like React complexity than Tailwind.

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

#80

Post by zmxz »

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…

Out of curiosity, have you used Tailwind and does your criticism come from having used it and not experiencing the progress or does your criticism come from reading how it works and not "feeling" it? I don't intend to follow up with discussion that convinces/dissuades/criticizes you in any way, I just ask purely out of curiosity.
Post reply on HN