Is Tailwind CSS the Future of CSS Frameworks?

Very few technologies in front-end development raise such a passionate divide as Tailwind CSS. From people madly in love with it claiming that “it fixes CSS” to detractors that discard it as “just abstracted inline styles”, It would seem that no month can go by on Tech Twitter without a flame war about Tailwind. 

However, I believe the arguments about Tailwind are rarely scoped to the framework itself, but are part of much deeper discussions. Let’s go through how it really works, dismantle some of the arguments from both camps, and address the most important question: is Tailwind the future of CSS?

What Is Tailwind CSS?

If we had to put it in a one-liner, we could say that Tailwind is a utility-first CSS framework, but I guess that won’t mean much if we don’t get into a little bit of CSS architecture first. 

Historically, one of the biggest challenges of CSS has been keeping things organized, especially as the team grows and more people work in the codebase.  Someone said that “the max number of people that can productively work on CSS is one”, and there’s quite a bit of truth behind that joke. If we don’t set clear guidelines, CSS can be particularly tricky to maintain. 

Several CSS architectures have been developed throughout the years to help address the issue. From the good ol’ Object Oriented CSS (OOCSS) to Block Element Modifier (BEM) and Scalable and Modular Architecture for CSS (SMACSS), numerous solutions have been proposed to keep our classes organized while embracing the power of semantics, the cascade, and the fundamental paradigm of separation of concerns. 

But as the web shifted towards a JavaScript-heavy modular architecture, we’ve seen other approaches emerge. In one way or another, these approaches seem to be more compatible with the modern web (or at least, with the people developing it): various flavors of CSS-In-JS, styled-components, and Utility-First CSS.