A lot of Tailwind's value comes not from the utility classes, but from the design system they enforce on the user, which is the most valued feature Tailwind offers, in my opinion.
I’ve always had the idea of producing a CSS design system with just a bunch of preset CSS variables to use like ‘margin-left: var(—-p2);’, as it’s close to how I end up using Tailwind lately; ‘@apply ml-2;’
Why use @apply for this? The classes are already simple and standardized. Now if I want to modify a component style I have to go find the css file with the @apply rule, which is how css normally used to work & kind of defeats the point of Tailwind IMO. I also have to grep the whole codebase and make sure nobody was using `.card-bg` or whatever in an unexpected spot. Plus you have to deal with a mixture of bespoke CSS classes and tailwind ones. Seems like a hassle!
It’s indeed a hassle if you were to mix your own CSS classes and Tailwind, but I don’t do that. Instead I use Tailwind for its design system and set of defaults.
My own CSS is classic BEM style, so very component like.
In hindsight I could easily replace Tailwind and just produce a set of CSS variable as a design system.
Yeah, the advantage of limiting colours and sizes to preset multiples made life a lot nicer for a while. Very easy to keep things looking consistent without needing to re-reference specific values.
But they keep making it more and more easy to do things like p-[7px] which rather defeats the point and there seems to be talk about changing the scales to just using px/rem numbers which feels like a complete abandonment of the idea.
Customise the tailwind config for your design system, add additional CSS in a css file for specific needs. Generating arbitrary values on the fly just muddies the system back up again.
Exactly. Bootstrap always had Utility Classes but they lost to Tailwind due to the focus on design and great examples/templates that Tailwind team focussed on early on and then the market took over.
