What are your thoughts on Tailwind CSS?

How about CSS injection vs page refreshing? I think this is a huge development impact?

(I actually registered, just to answer here)

I get the point, why tailwind css is so popular. Especially when you don't like or understand css. But there are some points, fans bring up, that I don't get or see different.

"Predefined values" or "no magic numbers"
Setting up a predefined subset of values is possible in sass/less or even with css custom properties like

$margin-2: 0.4rem; // sass/scss
--text-color-dark: #222; // css custom vars

And if you use css custom vars, there's even no delay because of compiling time.

"Naming classes is hard"
So what do they call their javascript functions or the like? a() b() wtf()?

"seperation of concern"
As @peerreynders nailed it. Concerns ar not features but content, markup, styling and functionality.

"I don't need to switch context"
So switching tabs in i.e. vscode is a context switch then?

"I can rapidly code my MVP"
But what about the project in the long term? What about maintenance?
Even in times of using components stylings may may get out of sync.

"the cascade"
You lose the power css gives you. You can style a very component, even with breakpoints and hover. But can you style by context?

.category-a .btn { background-color: red; }
.category-b .btn { background-color: green; }

or

.name-input + .btn { width: 100%; }

I'm really willing to give it a try, as I see the benefit for non-css devs in my teams, so I try to be as open as possible. But until now the "utility first" approach is not my thing.

I'm a frontend developer who is working with CSS/SCSS/Sass for a couple of years. Of course I thought about using TalwindCSS and tried it a couple of times. I like the principle and their docs/website are awesome. There are only two things that hold me to use it in the future:

1. Unlearning css. Writing CSS is most of the time more complex than writing code in Javascript. However if you know how to write 'good' CSS, using tailwind would not have many benefits in my opinion and will ensure you'll unlearn how to use css.
2. I don't prefer class names that are longer than the width of my screen.

For what I tested, it's more a step back to me than a revolution. I don't see where is the gain to give many classes to an element instead of giving it one or 2 classes and then apply the right CSS rules to that classes.

Maybe it can be cool with the latest frontend languages like vue or react that "encapsulate" some kind of components, but when you deal with standard html / css / javascript stack, it's more annoying than helping.

I knew the era of table design, then divs and CSS, I have the impression to go back where you put the style attribute directly on each elements (just replaced styles by classes).

I probably miss something

Rick & Morty: "Well, that just sounds like inline styles with extra steps."

Yes, one of the big problems with Bootstrap was that it came with a theme. TailWind fixes this by breaking everything down into smaller "utility" classes instead. This is a smart move, and noteworthy.

Another problem with Bootstrap (and early TailWind) was that it included a ton of unused styles, slowing your site down. TailWind uses PurgeCSS to fix this.

But there are still lots of other problems with Bootstrap that TailWind has, too. And they're unavoidable, despite how fervent TailWind's fanbase is. In fact, honestly, it's like a cult: "Here's a long post explaining why 'separation of concerns' doesn't apply here". Sorry, I don't want to drink the KoolAid.

HTML is concerned with semantics. CSS is concerned with presentation. Two concerns, separated.

But let's go further: Why is this good? Because if you're skilled at writing OOCSS you can write all of your HTML, with all of the styles you will need, without ever having to think about presentation. One pass and you're done.

A skilled front-end developer can write their HTML and never have to come back to it. That also means another developer can pick up the styles without needing to ever edit the HTML. In fact the only reason you would need to edit the HTML again is because the content of the page changed.

But then the TailWind fans try to compare it with other CSS frameworks ("it's smaller!")... as if being smaller than other CSS frameworks is some sort of accomplishment. Let's not overstate things, a "CSS framework" is just library of styles. Competent CSS developers shouldn't be using CSS frameworks with production websites. (Rapid prototyping, sure. Otherwise, no.) TailWind being smaller than Bootstrap isn't a sign of... anything.

Then there's talk about how small it is when it's gzipped. Again, as if this is some sort of accomplishment. Bootstrap 4 is only 20kb once it's been minified and gzipped. The problem has never been the payload size, the problem is the number of styles your browser has to parse! CSS is a render blocking resource, which means that the browser won't render anything until the CSSOM is constructed. Once 20kb of minified gzipped CSS has been ungzipped, that's 147kb of classes that need to be parsed!

The true comparison is the number of CSS selectors for a site written in TailWind vs good OOCSS. (The answer is obvious.)

So in the end, TailWind is good at two things:

1. Taking a CSS framework (aka library of CSS classes) and making it as small as possible. Given that CSS frameworks should only be used on prototypes, I don't know what the huge benefit of this is. ("My prototype is a bit faster!" Cool.)
2. It gives developers who hate CSS the ability to avoid CSS. And boy are they fervent about it.

That's it.

Actually it's good at one more thing: Making it harder to rapidly prototype because it doesn't come with a theme, so replying on you trying to make it look good instead. So maybe focussing on utility classes wasn't such a smart move after all.

Be honest, all you TailWind fans: You like it because you don't have to write CSS.

It feels like a boyfriend trying to convince his girlfriend that it's good for their relationship if he sleeps around: "Just read blog post and watch this video! See all the good arguments? It's GOOD for us if I sleep with other women!"

Uhuh, okay.

I'm not a fan. It feels more geared towards devs who hate writing or don't fully understand CSS because it essentially just moves your CSS into the HTML with some slight abstraction. Seeing 15+ utility classes on a single element hurts my soul.

Some more skeptical opinions about Tailwind CSS in particular or functional CSS in general:
The perils of functional CSS
I Tried Functional CSS and It Kinda Sucked
Thoughts on Tailwind CSS
Thoughts about Utility-First CSS Frameworks
Utility First and CSS Components: a reconciliation
Dave Shea (CSS Zen Garden) on Tachyons
Jeffrey Zeldman: Kiss My Classname

Also Adam Wathan points out in
CSS Utility Classes and "Separation of Concerns".

I still think there are a lot of use cases where it's more practical to create a CSS component ...but build them using utilities first

Aside: Jeremy Keith's response to that article

Extracting CSS components with @apply

Given that most people use Tailwind CSS with some kind of JS component framework or templating system they never see the need to "extract CSS components". Also the notion that CSS components only exist to eliminate duplication is restrictive - "descriptive and meaningful names" on class selectors serve to communicate (to the future developer) the intent behind applying that particular set of CSS properties. Style-centric class names only inform how an element should be styled rather than why the styles are being applied. CSS is a declarative language (IF this selector matches THEN apply these property values) - in my mind style-centric class selectors make it appear more imperative (which may contribute to the popularity of functional CSS/Tailwind CSS).

A Sass mixin could already do what Tailwind's @apply does:
When to use @extend; when to use a mixin

The need for Purgable HTML makes the class attribute values even more verbose (unless you are willing to manually manage selector exceptions).

In response to the seemingly indiscriminate popularity of Tailwind CSS Andy Bell published his CUBE CSS methodology (tutorial) supported by the Gorko utility class generator.

The first day i found it i said: I will use it.

I implemented one project (in an alternative @apply why, which is not intention of tailwind). Tailwind actually speeded up the process, but I said: NEVER AGAIN!

After few weeks reading reviews from others I was not sure.

Later I started missing Tailwind.

And finally I started using it for all my projects…

The first benefit of Tailwind - you don’t have to come up with ids and class names for your divs. I love this part. It actually a big time saver.

Second - if you use react / vue and need a component - tailwind is just made for that. If you see repeating yourself with classes - create a component

Third - I don’t have to write any .css file. Everything via html. I was afraid it’s like an inline-styles, but it’s not actually. It’s about using a design system.

The funny thing is when i was using bootstrap, i needed to visit homepage to find a code to copy paste it. even after 1 year using it. It took me few days with tailwind and I rarely visit docs...

I've been using tailwindcss for a couple of months, it is my favorite css tool after sass.

Good: Development efficiency; Easy to do the updates and responsive works
Bad: Sometimes a long class name; Hard to start at the beginning(an autocomplete plugin is useful)

For the autocomplete plugin, nothing works for React in Sublime at the moment, so I update another plugin tailwind-sublime-autocomplete to work with className in React, hope it can be helpful :)

Github: github.com/nerdy-doggy/tailwind-su...

I just started using it for a new project that is rather large. I've been a big tachyons fan for years but I felt I needed tailwind this time around because it allows for more fine tuned configuration options as well as some additional breakpoints. That being said, it is a lot heavier than tachyons so I added purgecss to the project, which, while not hard was some added complexity so as not to serve the entire library all the time. I also generally found the class names of tachyons a bit easier to memorize (that may just take more time also there are lot less to remember). Overall I definitely will be using tailwind a ton in the future but still keep tachyons in my back pocket for smaller projects where the restrictions of less allow me to develop faster.

NoThx

Well, I'm a big fan. I will try to respond without looking at what people already said.

I like how the framework is not opinionated design-wise. This help us style things from scratch. When opposed to something like Bootstrap, a button looks a certain way.

The class names are CSS-friendly. I mean it can be easily derived. align-items: center becomes items-center. We will have to look at documentation at lot in the beginning, but as we use we can easily derive. This also making building UI's faster.

And many more to go.

[Shameless Plug] I recorded a podcast episode on this recently - open.spotify.com/episode/07zmevkV4...

I'd recommend you use it.

I'm quite torn. In Bootstrap I notice I use more and more of the utility classes.
Then again I'm afraid that if I go all utility classes (like in Tailwind) I will end up repeating myself unless I highly componentise all my stuff. Otherwise if I want to change something I have to adjust all the classes everywhere on that type of component.

I can see this being less of a problem when working with things like React, but when I build a content site I don't want to put each button into a partial.