GoKawiilTailwind CSS is a very popular CSS framework among web developers. With no prior graphic design knowledge, it solves the standardization of spacing, colors, and sizes for you. And on top of that, if you are even slightly disorganized, it forces you into a working methodology based on building large structures out of simple utilities (Utility-First Fundamentals). Add to all that a documentation that is easy to understand with a flawless search.
In the past I used it on several projects, it helped me build user interfaces quickly. And despite all of that, it is a tool I would not recommend in every context. I am going to give you my point of view, my reasons, why you should think twice before using Tailwind CSS on medium or large projects. The only thing I ask of you is an open mind, self-criticism, and a willingness to learn.
You have to learn dozens of classes
Tailwind has thousands of utility classes. Even though the documentation is very good and the editor autocomplete helps a lot, there is a ceiling of basic classes you have to internalize. Most likely, at first you will develop with a browser tab open and the search box working nonstop. You spend time understanding the most appropriate way to apply each class. A slow process at the start. And if you have created your own classes that mix with Tailwind's, the difficulty grows.
It breaks the separation between structure and design
Tailwind CSS is a gigantic utility library, atomic classes with specific jobs. Unless you group classes with @apply , you end up including dozens of them in your HTML. This breaks the classic rule of separating structure from design, or HTML from CSS. It bloats the HTML, readability suffers, and you lose reusability.
That said, this one is worth pausing on, because it is the criticism that gets rebutted the most. Adam Wathan, the creator of Tailwind, wrote the foundational text of the defense, and his argument is a good one. The separation of concerns does not disappear, it changes direction. With "semantic" CSS, your CSS depends on the HTML; you can restyle the HTML, but your CSS is not reusable. With utilities, your HTML depends on the CSS; the CSS is reusable, but your HTML does not restyle itself. The coupling exists in both cases, only the direction of the arrow changes.
The argument holds in a world of components, where React or Vue already put logic, markup, and style in the same file. There, the separation by file type was already broken by you beforehand. But in a server-rendered project, with templates and classic CSS, the separation still makes complete sense. It is not a universal law, it is a decision that depends on your architecture.
Its names are not consistent
Its naming is not always coherent, at times it is opaque and tends to confuse. Look at the alignment classes. What is the difference between items-center , justify-center , text-center , and place-content-center ? The name is not intuitive and does not follow a clear pattern. In case you are curious, items-center aligns items in a flex container, justify-center aligns them on the main axis, text-center centers text, and place-content-center centers content in a grid. Let me rename them looking for coherence: flex-align-items-center , flex-justify-content-center , text-align-center , and grid-place-items-center . Do you notice the difference?
... continue reading