Readit NewsI 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.
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.
https://github.com/facebook/create-react-app/milestone/81?cl...
const PostImage = styled(Img).attrs({
className: `
duration-100
transform
transition-transform
ease-in
hover:scale-110
`
})``I'll take you up on that! Any good resources for learning tailwind that jibe particularly well with your “learning tool” approach?
<div class='text-base font-sans font-medium rounded-lg bg-gray-100 text-black py-3 text-center cursor-pointer'>Button</div>
.divxyz-default {
@extend text-base;
...
@extend bg-gray-100;
....
}
const sharedStyles = "..."
<CoolComponent className={`${sharedStyles} py-3`} />
<CoolComponent className={clsx(sharedStyles, "py-3")} />
<CoolComponent className={clsx(sharedStyles, someProp ? "py-3" : "py-4")} />Also, if you have written about your design system implementation with CSS Modules and CSS variables, I'd love to read it.
Having a name for each element in your markup is really powerful and useful, and it seems like the Tailwind approach exists specifically to avoid having to name things.
[0] https://tailwindcss.com/docs/extracting-components#extractin...
> 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?
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)