[dimal]

Exactly. This post is extremely unconvincing. The vast majority of the post is explaining the background of what CSS Modules is, what CSS-in-JS is, what Tailwind is... Then then "Implementation Strategy" section is three whole paragraphs, with no real details about the implementation. I honestly wonder how people would set up a design system with Tailwind. I don't see how to do it without it being a mess. I've done it with CSS Modules and CSS vars and it's lovely.

[BoorishBears]

I'll just throw out there that I'm someone who's been developing for a long time but never been able to get into web dev.

It just always feels clunky for me, there's way too many divergent approaches, best practices are constantly moving.

-

I'm designing a web frontend for an embedded project I'm working on and decided on Mithril + Typescript + Tailwind CSS and DaisyUI.

And it's the first time I've felt productive with web tooling.

Tailwind/Daisy UI makes so much more sense than any other styling approach I've ever tried.

I mean, is there a reason I wouldn't want to say an element is a "large red button" rather than a "setup-wizard-login-button" and defining that somewhere else?

Maybe I'm missing something that becomes a problem at a larger scale but for me this utility based approach is great.

[dimal]

Interesting. I've had a theory that Tailwind appeals to full-stack developers more than dedicated web front end developers. If you have to jump from context to context a lot, adding one new context (separate CSS), is an actual burden. All the extra abstraction can seem like a waste of time.

> I mean, is there a reason I wouldn't want to say an element is a "large red button" rather than a "setup-wizard-login-button" and defining that somewhere else

I wouldn't create a `setup-wizard-login-button` class. That's getting too granular. In the apps I've worked on there's usually been a `<Button>` component that encapsulates a lot more functionality than just being large and red. It deals with stuff like accessibility, custom disabled states, transitions, etc. It makes sense to encapsulate all of that into one component, then use something like `<Button type='primary'/>` everywhere. In this example, `primary` would map to a design token for a particular style that would handle all the permutations of how that style affects other states, transitions, etc. If you're just applying `large red button`, you're not getting any of that stuff, and I don't see a good reuse pattern for it. So I suppose it depends on how complicated your design system requirements are.

[01brett]

Author here, would you be interested to read a deep dive of how I'm using Tailwind? I wanted to include it here, but the addition made the post unbearably long.

Also, if you have written about your design system implementation with CSS Modules and CSS variables, I'd love to read it.

[spoiler]

Hi! I'm someone who worked with a designer closely to create a style guide/system and a React component library (using styled-components) for our product.

I don't see how Tailwind would've made our job any easier, or the implementation any "better" than what it is now. So, I'd definitely love to hear a non-vague (most Tailwind CSS praise I find around is very broad strokes or vague) success story.

Like, concrete examples where Tailwind reduced complexity or helped DX-wise, (etc) would be really appreciated. I believe there's many others like me who think Tailwind is kinda cool and we wouldn't mind playing with it in personal projects, but would hesitate to choose it at work/production...

I love the productivity idea its trying to sell me, but it sounds a bit... Wrong to me? Maybe I'm just too "old school", even if I'd like to think I'm keeping up lol.

[01brett]

Author here, it depends on what your designer has made. Our designer was using the Tailwind Figma file for the redesign with most of the defaults in place. We added our brand green and a different font to the default config.

When I was working through some of the component structures and spacing, the designer explained to me which Tailwind values he used most often and in what scenarios. For example, spacing around sections/containers was 24px or p-6; spacing within sections (like between form inputs) was 12px or p-3; and spacing within elements (like between button icon and text) was 6px or p-1.5.

While these were not absolutes in the redesign, they greatly sped up my scaffolding and allowed my first passes to be either dead-on or close enough to reason about. And when it was close enough (but not dead-on), toggling up or down a value usually settled it to match the mocks.

Personally, this was the easiest time I've had for getting an implementation "pixel perfect." I chalk this up as a design system win more than Tailwind. Any well-defined design system would open up these collaboration benefits. I found Tailwind to be an asset to these both for my own DX and for collaboration with my designer. I think Theme UI or styled-components could fit that goal just as well.

[dimal]

Ah, I see. I was working on the web portion of a system that was meant to encompass web, mobile, and smart TV devices, and was very custom. The designers would not have even considered using off-the-shelf Tailwind values, and the mobile teams would not have wanted to translate a web-framework's values into mobile-land. I suppose if you have an organization that's ok with that constraint, that makes it more doable.

> I chalk this up as a design system win more than Tailwind. Any well-defined design system would open up these collaboration benefits. I found Tailwind to be an asset to these both for my own DX and for collaboration with my designer.

Yeah, this seems like the real takeaway. If you have a framework that gives you defaults for the design system, that reduces the friction even more, but I tend to work on very custom stuff where framework defaults won't be appropriate. Are the Tailwind values customizable, so you can use the same Tailwind structure, but have your designers specify their own tokens?

[01brett]

Absolutely. The Tailwind config makes this really powerful to extend or override. You can reuse the same API for things like spacing with your own values/scale or make your own.

The Tailwind docs get into it a bit as you can see here: https://tailwindcss.com/docs/configuration#theme

Here is the spacing section in my config where I've extended the default with interstitial values. What's really cool is these propagate to all the spacing utilities (padding, margin, margin between, etc)

  spacing: {
      0.75: '0.1875rem',
      1.25: '0.3125rem',
      1.75: '0.4375rem',
      2.25: '0.5625rem',
      2.75: '0.6875rem',
      3.25: '0.8125rem',
      4.5: '1.125rem',
      4.75: '1.1875rem',
  }

[spoiler]

Thank you for the detailed write up!

I have to agree with a sibling comment:

    > > I chalk this up as a design system win more than Tailwind. Any well-defined design system would open up these collaboration benefits. I found Tailwind to be an asset to these both for my own DX and for collaboration with my designer.  
    >  
    > Yeah, this seems like the real takeaway

And to add:

> Our designer was using the Tailwind Figma file for the redesign with most of the defaults in place.

I never really thought of Tailwind as something that provides design primitives designers could also use for their designs.

If everyone on the team knows how to use Tailwind, I can see how it helps productivity. Everyone's using the same primitives and they're speaking the same design "dialect" (for a lack of better word).

Your example with negative/white space units is a really great, because it illustrates how it dispells ambiguity around units and numbers, and it brings an vocabulary for talking about those units. For example, I really like that `p-3` means the same thing to both the designer and the developer now.

Before a designer would have some systems for managing various design sub-systems (ie typography, colour, spacing), that developers rarely (ie never) spend time understanding, which then removed the system's internal consistency, which in turn affects its perceived/external consistency.

Tailwind kinda leaks the design-system's implementation details, which is great for developers, because now they don't have to know anything about design systems, just use what the designer provided.

[dimal]

Absolutely, I would love to see a longer write up! I’m definitely in the CSS Modules camp, but with so many people saying that Tailwind is great, I feel like there has to be something there. I want to do a deep dive into it at some point and see if I can make something with it that works with my brain. It’s such a different way of approaching the problem.

As for my experience with CSS Modules, I don’t have a blog, but I’ve been thinking of starting one and writing up some of my experiences. Can’t promise anything though.

[the_other]

I too would like to read this.

Tailwind seems to force users to learn its API on top of having to learn CSS, without removing the need to learn the app-specific conventions you’d have to use/create when using Components or classNames anyway.

What benefit does it provide? All I could glean from your post was that you used it and got the job done.