DEV Community

What are your thoughts on Tailwind CSS?

Nick Taylor on January 27, 2020

Photo by Mahkeo on Unsplash I'm curious what people's thoughts are on Tailwind CSS. I'm a big fan of Refactoring UI (part of my frontend developer...

Read full post

Vasyl Boroviak • Jan 28 '20 • Edited

None had mentioned yet that it enables non-css devs to do css. I'm a backend dev who wrote a beautiful Web app not knowing css language.
Being a css hater I'm a tailwind lover. ❤️

My .vue files do not have <style> blocks. All visual styling is in <template> part.

Ashley Sheridan • Feb 8 '20

As a backend dev, don't you find this violates separation of concerns? The HTML should have no knowledge or care about the appearance it has, which Tailwind classes do. However, Tailwind could be used if you're using a preprocessor like SASS or LESS, using classes in the HTML that describe the element/component and then building your CSS based on extending the Tailwind styles.

Vasyl Boroviak • Feb 8 '20

I find that most developers misuse the word "concern". Often Frontend devs think that technology is concern. But CSS or HTML or JavaScript are not concerns. They are technologies, languages.

Here is what Wikipedia says:

When concerns are well-separated, there are more opportunities for module upgrade, reuse, and independent development. Hiding the implementation details of modules behind an interface enables improving or modifying a single concern's section of code without having to know the details of other sections and without having to make corresponding changes to those other sections.

The less files you need to edit to make a necessary change - the better your concerns are separated. (Hence I like Vue.js.)

In other words a concern is: a searchable drop down component, or a user profile page, or a login form, or feature of some kind. But not a programming language.

Tailwind is the next step in the concern separation game. My HTML and classes (and some JavaScript) are blended together within the <template>. It allows me to drop <style> and the css language altogether. Thus concentrating my concern more within the <template>.

Ashley Sheridan • Feb 9 '20

Having fewer files to update doesn't really mean you've separated concerns. An extreme example is the typical spaghetti code where your entire app logic is within 1 or 2 files.

Blending multiple languages together into a single file feels very much like the opposite of SoC. The code is tightly coupled both ways, the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future. Think about it in terms of dependency injection. You should remove tight coupling, and ensure that each layer only knows about the it's immediate relations.

Vasyl Boroviak • Feb 10 '20 • Edited

the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future.

It's actually vice versa. It was very easy to move and change a component written with Tailwind. Extremaly easy. 😉

Ashley Sheridan • Feb 11 '20

But you're putting the responsibility of appearance on the HTML, which it shouldn't care about. I realise it makes things easier for a backend dev that doesn't know much about the front end, but it's basically the equivalent of not using dependency injection because you prefer each class to create all the instances of everything it needs by itself. Sure, it works, and it can be done very quickly, but it's not clean, and it isn't going to be very maintainable at scale.

Moshe Uminer • Jan 27 '20

I'm a big fan of tailwind. In my eyes, the biggest advantage is the fact that there is a range of preset values for everything.

Let's take coloring for an example. Using tailwind you don't need to figure out a complete color palette beforehand, because tailwind will come with 9 shades of every color. And if you don't like the exact color, you can change the configuration. The same is with margins, instead of fretting over the distance, just use a preset. Which margin preset looks better? Take it. And it is so with all of tailwind's classes.

I should note, that tailwind is best used with a component framework, because you definitely don't want to right the same 10 classes 3 times. The framework can take care of the repetition for you.

By the way, the tailwind website had some screencasts for design using tailwind.

You haven't mentioned why you find tailwind overwhelming, but I will guess that it feels like there are simply too many classes to keep track of. I had a similar problem, but downloading the tailwind plugin for vscode gives me code completion. So now I just need to remember that all margin classes start with m-, for example, and the plugin shows all possible classes and their values.

Shawn McElroy • Jan 27 '20

I have learned not to worry about the volume of css classes because the way it's designed we won't be using them all. It's basically ergonomics. Like if I want left/right padding on medium and above it's md:px-2. I can almost predict what the css classes will be. And it's usually right.
If you ask me, that's great framework design.

ZediWards • Jan 31 '20

I am also using it as a means of making design and layout choices easier by limiting myself to tailwinds options. The vscode extension gives me autocomplete with all of that properties options and the actual css property so I dont forget what css I'm actually writing.

Nick Taylor • Jan 27 '20 • Edited

Thanks for sharing your thoughts on Tailwind.

Yeah, I wrote "potentially" overwhelming. Not saying it is, just an impression before having used it. Thanks for the mention of the VS Code plugin and I'm definitely going to watch those screencasts.

Shaiju T • May 18 '20

Why tailwind is better than bootstrap ?

Rick Mills • Jan 28 '20 • Edited

It took me a while to get my head around its benefits over something like Bootstrap, and I did make mistakes along the way. However now I can safely say its sped up development for me significantly.

The biggest thing to remember when using it is that whilst you can just stick every single option on your class, they can quickly become pretty overwhelming to manage.

This has been accounted for though. Tailwind has an @apply method you can use in your CSS/Less/Sass that allows you to create reusable components.

So for example lets assume you've got a box you use all over the place, and its classes look like this:

<div class="mx-2 text-center border-1 border-blue-800 bg-white shadow rounded">

In your CSS you can do this instead:

.card {
    @apply mx-2 text-center border-1 border-blue-800 bg-white shadow rounded;
}

Or to be even more tidy, this:

.card {
    @apply mx-2;
    @apply text-center;
    @apply border-1;
    @apply border-blue-800;
    @apply bg-white;
    @apply shadow;
    @apply rounded;
}

Then on your div you simply have:

<div class="card">

It ends up making it super easy to build out components. Make no mistake though - there is a learning curve, but in my experience so far it's been totally worth it.

Feel free to poke around my first attempt at using it here, I went with a raw copy of tailwind and no custom css for this one, given the size of the site it didn't really need its own stylesheet. You can also use purgecss to strip out any unwanted css to make load times super quick :)

Bernhard Hörmann • Oct 6 '20 • Edited

Thats a very important feature, but it does then basically exactly what all other frameworks (bootstrap, etc.) does, the only difference is, that you use tailwind instead of css. What is the benefit of using for example

Tailwind

.card {
    @apply mx-2;
    @apply rounded;
}

CSS

.card {
    margin: 0.5rem;
    border-radius: .25rem!important;
}

or even using variables in SCSS/Sass/Less with the same effect?

Sergio Daniel Xalambrí • Oct 6 '20

The idea is that you can use the Tailwind design tokens (the classes) to keep consistency, it also removes magic numbers from your CSS (why .5rem? mx-2 is part of a scale and you can understand the reason behind it).

Also Tailwind team recommends avoiding using @apply, specially if you are using a component based frontend framework like React/Vue/Angular, because now your components are in the framework not in the CSS.

Bernhard Hörmann • Oct 6 '20 • Edited

Sorry, but that is no argument. mx-2 is just another representation of .5rem and the scale is exactly the same since mx-4 is twice of .5rem. The only difference is that you are using some kind of "proprietary" unit instead of standard unit rem. To understand rem, you only need ot understand CSS. To understand mx-2 you need to know tailwind. And if you don't like magical numbers, all css preprocessors understand variables.

And of course is the tailwind team against apply, since its the opposit of what they do.

I dont see that big advantage of using tailwind in comparison of just using inline css.

I some cases, I even HATE Tailwind, when you don't have the full controll of the output html. Just a example - Laravel nova. They use tailwind there. Its almost impossible to change a lot of stuff without really hacky css rules (and they even have some extra classes like btn or card, but way to less of them)

Robert Denus • Feb 20 '21

Berhard its more about the design SYSTEM. Applying this to your comment "to understand mx-2 you need to know tailwind" -> you would need to say: "... need to know your design system". And this makes sense, look at is a contract between designer and developer. Therefore using agreed tokens is a big help instead of any not-systemized values like rem, where you would need to measure by hand any spacings. a good read here: medium.com/swlh/design-system-base...

Jesse Sutherland • Mar 13 '21

This is the most underrated use of TW CSS! TW as a foundation of a design system that you can specify your own utilties for, or convert into more 'conventional' BEM via @apply is a really good use case IMO. The way I'm currently doing it is like this:

Specify initial TW config w/ custom colors etc
Prototype components using utility classes
When 'done' use @apply to map those utilties into a BEM style CSS file, which can be re-used later by consumer of the design system, but since its TW based can also be easily purged - if I don't use that class in my docs/component templates, its not exported to the library

CSS-in-JS offers similar structure, but TW is probably (or at least the most popular) CSS-first framework that allows for such easy and systematic style composition/extension.

The next thing I'm investigating is how to integrate 'design tokens' into my TW config file - and there's a couple OSS projects that might fit the bill such as Style Dictionary.

Sean G. Wright • Jan 27 '20 • Edited

Adam Wathan, the maintainer of TailwindCSS, wrote an article a couple years ago about the differences in CSS architecture that exist between traditional approaches (BEM, SMACSS) and atomic/utility approaches.

Here's that article: adamwathan.me/css-utility-classes-...

I recommend everyone read it.

Adam doesn't declare that one approach is bad and another is good. Instead he provides insight into what the constraints are of each and what use-cases each might be good for.

In the end he argues that most of the sites/apps he works on benefit from the approach provided by TailwindCSS and other similar libraries (Bulma, Tachyons, even Bootstrap's utility classes).

I think understanding why we should use TailwindCSS is as important (or more) as asking the question "does Tailwind make me more productive?"

And yes, I like TailwindCSS because it fits the type of work that I find myself regularly doing.

Melissa McEwen • Jan 27 '20

Ooo love that post, that answers a lot of my concerns.

johndetlefs • Sep 24 '20

Cracking article - ta for posting - hadn't really thought about separation of concerns as comprehensively as this article, ended up making me want to give tailwind a try!

Nick Taylor • Jan 27 '20

Thanks for the thoughtful response and link to Adam's post. Definitely going to give it a read. I'm eager to try it out, but thought it'd be fun to get some feedback from the community. Cheers. 😎

Andrew Brown 🇨🇦 • Jan 27 '20

I tried so hard to make it work, but I felt I was doing the same amount of work but I've just shifted the work someplace else.

I think people are just better off making a handful of utility classes and scoping css per page/component.

Magnus Skog • Jan 27 '20

Huge fan. I was using Bulma for all my project and while that is still a great choice I find that Tailwind is a better fit for me. I can make something that looks half decent with it so that has to be worth something!

Peyton McGinnis • Jan 27 '20 • Edited

I was a little put off by Tailwind when I first looked at the examples in the documentation.

Why would I put all these classes in my HTML? Why wouldn't I just use Sass mixins?

But I decided to give it a shot, and oh man am I glad I did.

Once you start seeing patterns and memorizing the basic utility classes, it becomes an absolute breeze to style any component or section of your page might have.

I found it especially great for using flexbox, simply specifying flex and flex-1, flex-grow, flex-shrink, etc.

And the configuration and adding custom classes is very simple and intuitive once you learn it, which doesn't take long at all.

Again, it does seem off-putting at first, but as the docs themselves say,

You just have to try it.

Jeremy Brayton • Jan 27 '20

This mirrors the path I took almost completely. I’ve had relatively lackluster CSS skills and at first drinking from the firehose was really off-putting. There is a ton of stuff to learn if you’re trying to get a handle on everything at once. I found it much easier to retain very little and to just browse the docs whenever I need to implement something. Then when a coworker who is more versed in CSS implements something, I pick it apart and start using the same technique.

Even in taking bite sized chunks of knowledge there’s room for more advanced topics like figuring out how purge css strips extra selectors or how to apply themes. Fortunately there’s also a huge supply of examples as I’ve been fortunate enough to find just about everything I’ve been looking for with a few short google searches.

I also happen to be a fan of letting other people choose sane defaults. It’s not that I’m incapable but it allows me to keep my brain focused on what I need to finish, not get stuck in the minutiae. I also feel way more productive, though that could be a product of applying more knowledge. Even though it lacks the JavaScript components of a Bootstrap, I find I don’t really mind implementing behavior from scratch.

Ben Lovy • Jan 27 '20 • Edited

I'm using it for the first time currently to style my Stencil app.

I think I like it, but I'm also not sure if I'm missing the point. To use it with Stencil, I'm still keeping separate CSS files and applying these template classes manually:

.subtitle {
  @apply italic;
}

.name {
  @apply text-2xl font-extrabold;
}

.cv-links {
  @apply flex mb-4;
}

So, while the built-in utility classes are handy, in a lot of cases I think I could probably be doing just fine without Tailwind. This is kinda like how I'd write up plain CSS anyway. The one big thing I like is the flex spacing - it's pretty easy to tweak and play with to get what you need:

.cv-section {
  @apply flex mb-4;
}

.cv-heading-section {
  @apply w-1/3 px-2;
}

.cv-body-section {
  @apply w-1/2 px-2;
}

.homeaddress {
  @apply float-right;
}

I have definitely not spent enough time defining my utility classes and have repeated segments in a few spots across different components, that might push me more thoroughly to the "pro" camp once I get around to it. It is super intuitive and easy to use, though, I like how quickly I can throw a new idea on my page without diving through a search engine rabbit hole. The docs right on the main page have covered every question I've had so far. I generally dislike CSS and building frontend styling, it's a necessary evil from my perspective, so the frictionless experience is pretty great.

Moshe Uminer • Jan 27 '20 • Edited

Hi Ben, I also took that approach before, and while it isn't the recommended way to use tailwind, you do still get one of the big benefits: a range of presets. It means that you won't start tweaking every color and margin that you add, unless you decide it really is necessary (see my comment above). As you mentioned with flex spacing, for example.

Ben Lovy • Jan 27 '20

You're right, I don't think I'd fully realized exactly how much of a help the presets really are. I've skipped a lot of work by using Tailwind to get my page to the point it's currently at, and didn't even notice because it was so easy to do but still felt as granular as doing it manually.

wwayne • Feb 9 '20

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...

Aravind Balla • Jan 29 '20

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.

Saurabh Sharma • Jan 27 '20

It's great we used it before we went into making Shopify apps. But sometimes things like purge CSS and using React components as a way to reuse logic makes me things we need really need a framework that just makes a 10 character CSS property into 2 i.e flex instead of {{ display: flex}}

Sebastian Nitu • Jan 7 '21

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.

Kal Starkis • Jan 27 '21 • Edited

Well said. The sheer popularity of atomic/utility CSS makes me question myself, but only a little. The old emperor (presentational markup) is back with some new clothes, but his unsightly parts are still on full display. It may well be that those who heed the 'just try it' cry do find that it makes them happy, but it's a biased sample because the devs who try it are the ones who don't cry when they see 15+ utility classes on a single element!

Vaibhav Khulbe • Jan 27 '20

I totally like Tailwind. The fact that it's not just another CSS framework but is a utility-based framework is great! 💯

I wrote an article dedicated to my first-time use of Tailwind, here's a snippet:

What sets apart Tailwind is that instead of some predesigned components, it provides low-level utility classes that we can use to completely customize it!

Of course, it's fairly new as compared to other CSS frameworks like Bulma, Bootstrap or Materialize, but I'm sure in coming years it'll boom. I like the fact that new features are added every now and then to this with good community support.

Drew Town • Jan 27 '20

I've written a few articles now about Tailwind and how much I like it. Tailwind works best when used with a component/partials system and I pretty much would consider it a requirement at this point.

One of my favorite parts of Tailwind is the limitations it imposes on your choice by using a constrained set of options. Consistency is hard and limiting your options to a small subset makes managing choice easy.

I really like using it on my personal blog and I really like the fact that is less than <5kb gziped.

Ryan Smith • Jan 27 '20

It appeals to me by providing the benefits of a pre-styled library while still allowing you to create a custom design. The downside is that the design still needs to be created by the developer. Not all developers are detail-oriented when it comes to the front-end, so I could see it being a challenge for some. I have also seen many cases where Bootstrap users do not apply classes/markup correctly leading to elements that do not look as the maintainers intended, so Tailwind's added complexity with applying classes may lead to some designs that are not as polished.

They are also working on Tailwind UI, which I believe will be a paid set of templates created using Tailwind. I think that will help to bridge the gap with the other Bootstrap-like frameworks but I'm not sure if they are providing any parts of it for free. Last I heard, they are expecting to release it in February.

Aleksey Razbakov • May 6 '20

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...

peerreynders • Sep 2 '20 • Edited

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.

Alexandre Valsamou-Stanislawski • Jan 27 '20

Hey 👋 thanks for asking 😃

I'm a massive fan of having a set of values already sorted out for me. As a developer/product maker, we should always aim for repeatability. And you get that with Tailwind as it shrinks down the number you get to choose from:

only a subset of colors instead of the whole color spectrum
responsive breakdowns instead of the ones that you've just looked up on google
margins and paddings instead of every possible value in the integer set

All of this is configurable, so you get to keep the limited subset with the values that are harmonious with the design.

I hope this helps 🙇‍♂️

Nick Taylor • Jan 27 '20 • Edited

Awesome. Merci pour tes pensés Alexandre. A+

Zane Milakovic • Jan 27 '20

Big fan. It takes a few hours to get use too it.

But it speeds up Development a lot. The defaults are pretty nice, and easy to change.

We moved our entire frontend too it. I love putti by everything in html, even though it makes the markup slightly ugly. I am looking forward to pairing this with Alpine Js in the future.

Mike • Jan 28 '20

I used it to develop a fairly complicated web app, and it fit my work style perfectly. Love it.

Not having to fight a premade UI framework, or have to context switch to a CSS file to iterate on styling tweaks is a real time saver.

Dennis Keirsgieter • Jan 27 '20

While i like the idea after trying it (first i was like omg so much classes!?) i am not sure i will use it for something production wise.. I have my doubts about the css file size after purging everything not used vs writing my own css for big websites.. And unfortunately i don't have the time to port one of our bigger client websites to tailwind just for fun and actually compare the file size :)

Paweł Kowalski • Jan 27 '20

I like it.

In a new project its a no brainer (especially for those performance oriented).

Im slowly growing to rewrite my companys docs site from bootstrap+custom css to tailwind. This will be interesting experience.

Melissa McEwen • Jan 27 '20

It saves me a lot of time when working with an unfamiliar React codebase. I know if there is Tailwind there are standard things that I can use.

That said I'm a little skeptical of the long term effects of having to go into every single component to change a style if a designer decides we're doing something different, but I'm not a Tailwind expert so maybe there are architectural choices that can help mitigate this.

Travis Werbelow • Jan 27 '20

I really enjoy it. I have used it for a handful of personal projects and it's great to work with. When I have to use something else, for example at work, I miss it.

It makes knocking something out design-wise, pretty quick and easy.

neoan • Jan 28 '20

I am currently using tailwind in a project and absolutely love it. It's relatively straight forward and combined with postCSS extremely powerful and modifiable.

I noticed that I started to "live design". So let's say you play around with an input until you get to the point where you say "yes, this is how my inputs are going to look like/behave". At that point you ask yourself which of the used classes will always apply and then write your @apply accordingly.

After a while you will notice that you kind of wrote your own CSS framework in doing so.

However, the amount of CSS you will write isn't as much as you'd expect.

So personally - yes, it's awesome!

John Arkema • Jan 27 '20

I decided to give it a try after a co-worker sent me this article

adamwathan.me/css-utility-classes-...
Writer does work on Tailwindcss

So far I am really enjoying not have a giant css or sass style sheet to deal with. Its got great built in breakpoints and handles responsive design well.

Plan to keep using it in the future!

Saugat Rai • Jan 28 '20

I have tried Tailwind CSS in one of our projects. The first few days was confusing and difficult. But once you get the gist of how p-1 and pl-1 works then it's all easy and fast. The implementation is faster than ever. Responsive is also handled way easily.

Haoran • Jan 28 '20

I feel like everyone I've seen who's a fan of Tailwind is a developer. What do web designers think about it?

For my last two teams, at least, my web designer is still the gatekeeper of good web design, so I defer to them and don't touch the CSS.

Tim • Jan 28 '20

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.

Mike Rispoli • Jan 31 '20

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.

Daniel Schulz • Jan 28 '20

A bit of criticism on my side.
Tailwind (and atomic CSS b design) miss out on the cascade.
Many people refer to it being easy to learn because of this or enabling non-frontend Devs to write CSS, but that's only half true.
What tailwind enables you is write coherent styles and not breaking you CSS file. What it discourages you from is writing an effective design system.
You'd have to deliberatlely define your styles on each component instead of cascading your styles down. Your components become more robust that way, but also more repetitive.
Another shortcoming is the binding of styles to the DOM. I have a paragraph about that here: A bit of criticism on my side.
Tailwind (and atomic CSS b design) miss out on the cascade.
Many people refer to it being easy to learn because of this or enabling non-frontend Devs to write CSS, but that's only half true.
What tailwind enables you is write coherent styles and not breaking you CSS file. What it discourages you from is writing an effective design system.
You'd have to deliberatlely define your styles on each component instead of cascading your styles down. Your components become more robust that way, but also more repetitive.
Another shortcoming is the binding of styles to the DOM. I have a paragraph about that here: dev.to/iamschulz/in-defense-of-the...

Manuel Schulz • May 12 '21

(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; }

.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.

Jannik Wempe • Jan 28 '20

Awesome discussion going on here :-) I am myself still looking for my perfect fit in regard to styling. I moved from Bootstrap and tried Bulma (which I liked more), but after using React I am still not sure if I prefer scss modules or styled components. On the other hand I always liked the approach of TailwindCSS, but also thought it could be overwhelming in the beginning.

Is there anybody preferring TailwindCSS in components over (s)css modules / styled components? Or the other way around? Why?

Alex • Apr 23 '21

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

JohnnyWalker2K1 • Jan 18 '21 • Edited

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:

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.)
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.

Mike Burgess • Feb 11 '21 • Edited

Whilst I don't necessarily agree with everything you said, it's a good post with some interesting points raised.

I do have you pull you up on this though - "Competent CSS developers shouldn't be using CSS frameworks with production websites".

It really doesn't matter what you used to accomplish it, but what really matters is if people are willing to use or pay for your product?

If two production sites both look good and one happens to be using a CSS framework and the other was painstakingly hand-crafted, what does it matter?

If they portray the right brand image and drive usage / revenue, I'd argue the latter was a waste of time to a certain extent?

Anyhow, this thread was a good read, very lively!

Anthony R. • Jan 28 '20

I am a big fan of tailwind. I would not use it in a "big project". But it's okay for me if you use it for an MVP or a small side project.

Jim Burbridge • Jan 27 '20

I think it's interesting, and I'm aiming to use it going forward. I'm hoping that the tooling for VSCode has improved since last I fiddled with it (about a year ago).