Tailwind is the best thing that has happened to CSS Frameworks in the last 10 years.
* Define the essence of your design in a JSON - typography, colors, spacings, shadows, borders et al.
* Anyone in the team including backend developers can create new interface components without waiting on a designer, thanks to well-defined scales that compose well.
* The component (HTML+CSS) is the unit of abstraction. eg: "ProfileCard". Inside ProfileCard you'll use Tailwind's utility classes to build your component. You reuse this component everywhere, and if you have to "change a button's padding across the product" (which to me is far too rare) you open your component files and change them there.
* It is so easy to build UIs - you don't have to name every single element in the DOM - these names are _only_ to act as "hooks" into the CSS, and serve no abstraction. With Utility classes you can just assemble them in the HTML without touching the CSS
* Tailwind has excellent documentation and great conventions - this means between projects all you need to know is their particular scale. Don't have to learn a new UI framework everytime.
* Consistency, consistency! Thanks to design scales.
* Works so well for custom UIs. Have your designer do absolutely original designs in Sketch, and first transcribe their scales into tailwind.config.js, and voila! start pushing out its HTML at breakneck speed.
I mean a lot of those things were possible with bootstrap-sass years ago.
> Define the essence of your design in a JSON - typography, colors, spacings, shadows, borders et al.
_variables.sass
> Anyone in the team including backend developers can create new interface components without waiting on a designer, thanks to well-defined scales that compose well.
This is true, but is solved by any sort of component system and not unique to tailwind.
> The component (HTML+CSS) is the unit of abstraction. eg: "ProfileCard". Inside ProfileCard you'll use Tailwind's utility classes to build your component. You reuse this component everywhere, and if you have to "change a button's padding across the product" (which to me is far too rare) you open your component files and change them there.
Why would you change a padding in multiple files when you can set `$base_padding: 10px`?
> It is so easy to build UIs - you don't have to name every single element in the DOM - these names are _only_ to act as "hooks" into the CSS, and serve no abstraction. With Utility classes you can just assemble them in the HTML without touching the CSS
Going by the first example in the linked article, something like "text-grey-dark" seems like an awful idea when what it really means is "text-quiet". Heck in their example "dark" is _lighter_ than the surrounding text.
_variables.sass works if you're using BEM. But now you have two component-like things: BEM classes, and the components themselves. BEM solves the issues inherent in nested CSS (cascade, inheritance, multiple selectors, specificity) by forcing us to never nest them, and instead having to name every single element in HTML. Though they look semantic, they are not truly reusable since they are coupled deeply with the markup. But with Tailwind, your component is your unit of abstraction and you don't have to name everything just for the sake of hooking up the HTML with CSS.
But you can even do BEM with Tailwind if you really want to with @apply.
> Why would you change a padding in multiple files when you can set `$base_padding: 10px`?
Neatly written CSS that uses variables for design scales are a good thing to have, but without any kind of tooling help, it is really difficult to keep it consistent. Tailwind on the other hand gives you the affordance for that - a "pit of success" because you never have to define magic values and instead use pre-defined functional CSS classes.
Regarding colors - you can use "text-quiet" or "text-title" etc. - the names are fully in your control and can be set in the configuration JSON file.
* Define the essence of your design in a JSON - typography, colors, spacings, shadows, borders et al.
* Anyone in the team including backend developers can create new interface components without waiting on a designer, thanks to well-defined scales that compose well.
* The component (HTML+CSS) is the unit of abstraction. eg: "ProfileCard". Inside ProfileCard you'll use Tailwind's utility classes to build your component. You reuse this component everywhere, and if you have to "change a button's padding across the product" (which to me is far too rare) you open your component files and change them there.
* It is so easy to build UIs - you don't have to name every single element in the DOM - these names are _only_ to act as "hooks" into the CSS, and serve no abstraction. With Utility classes you can just assemble them in the HTML without touching the CSS
* Tailwind has excellent documentation and great conventions - this means between projects all you need to know is their particular scale. Don't have to learn a new UI framework everytime.
* Consistency, consistency! Thanks to design scales.
* Works so well for custom UIs. Have your designer do absolutely original designs in Sketch, and first transcribe their scales into tailwind.config.js, and voila! start pushing out its HTML at breakneck speed.