Few Front-End tooling discussions are as contentious as the debate around Tailwind CSS. Like eating raw fish or reading poetry, you either love it or hate it.
Maybe you've heard both sides of the argument and are wondering if learning Tailwind is necessary as a CSS beginner. Or you've skimmed at the docs but don't understand its utility.
If you are asking yourself "Why is Tailwind CSS such hot stuff?" – this post is for you.
I'll list my reasons why Tailwind CSS could be the right CSS framework for you or your team. While I only use Tailwind for my personal projects, I just spent the last few weeks auditing CSS stylesheets from a few different teams in my company and Tailwind definitely could improve some of them.
The Skinny on Tailwind
So what is Tailwind CSS? It is a utility-first CSS framework that takes the atomic approach to styling. Every allowed CSS value gets a class name. For example, md:py-8 applies size 8 padding in the y-axis under medium viewport size and above. You then stack the class names together to achieve the style you want.
Some folks simply couldn't get over the abundance of class names for what is essentially short-hand inline CSS. Tailwind classes act as an API layer on top of existing CSS properties, leading to some extra cognitive overhead. When I use tailwind, I always have the docs open.
On the other hand, fans swear by the Framework. It seems to cure everything from large CSS files to rheumatoid arthritis. A lot of the rationale is in the 'you gotta use it to believe it' category – including the Tailwind Docs – so I'll break down its benefits from my perspective.
Configurable Design System
I often see Tailwind called 'CSS shortcut' or compared to vanilla CSS. Truth is, it's both more and less than that. Take this testimonial from the Tailwind homepage:
I have no design skills and with Tailwind I can actually make good looking websites with ease and it's everything I ever wanted in a CSS framework.
If Tailwind is just CSS shortcuts, then how would produce better-looking sites? It wouldn't. Tailwind out of the box is already opinionated, it has built-in defaults for font scale, color palette, and spacing scale. It's these constraints that allow a non-designer to create good-looking sites.
What separates Tailwind from other CSS frameworks like BootStrap and Material is how easily customizable it is. While default Tailwind is opinionated, its opinions are very weakly held. This means you get the power of a full-fledge design system but with the customizability of vanilla CSS. Be warned though, Tailwind's default values are tweaked by professional designers, so your customization may not look as good.
This also means Tailwind is great for prototyping and MVP creation. Once your product is mature, the bar for updating default Tailwind styles with your own Design System is low. It's much lower than Bootstrap or MUI.
Benefit One: Tailwind forces devs to work with a customizable Design System.
The Selector Problem
For me, using CSS selectors is a bit like going to a buffet, I always end up with more stuff on my plate than my body needs (needs work).
The root of the problem is there's often no predictable cause-and-effect. Fundamentally and outside of globals, we tend to only make changes to one part of a page at a time. But CSS selector's ability to cast a wide net and the cascade's ability to propagate that change down the CSSOM, all too often we change more than what we originally intended to. And always in unintended ways. To borrow an old CSS joke:
Two CSS properties walk into a bar.
A barstool in a completely different bar falls over.16:10 PM - 28 Jul 2014
This problem is especially painful for large teams or codebase with external CSS usage. With tight deadlines and new team members, it's not uncommon to trace a style bug into some weird corner of the attic underline 45 of overwrites.css.
Solutions to the selector problem fall in a spectrum. On one extreme you see folks abandoning selectors entirely via inline style or Styled Components. On the other extreme, you have rigid selector layers such as ITCSS. The goal? Give every selector a home where it belongs. Tailwind's atomic CSS philosophy is also somewhere in the middle and closer to inline style. All CSS styles belong to one class – @apply is an antipattern – and the class is only responsible for one or at most a few CSS properties.
No specificity overwrites are needed. No stylesheets to organize. No need to come up with descriptive class names just to hang selectors on.
Benefit Two: Tailwind makes managing a large codebase easier by flattening selector levels and removing stylesheet organization.
Ready-Made Workflow
Another Tailwind benefit often not talked about is it's a complete and sensible workflow in a box. You are not just buying into the framework, you are buying into a way of styling your website. A darn good one at that too.
Tailwind forces a comprehensive designer/developer handoff process. Before a single line of CSS is written, a developer must translate the designer's specs and scales into the project's tailwind.config.js. None systematic values are simply not exposed via Tailwind. Though turning design style guides into Sass / CSS variables is a part of generally accepted styling practices, in practice, this step often gets overlooked or is not continuously worked on.
In day-to-day development, devs are only working with the HTML component they are currently working on. Cognitive capacity once used for selector wrangling, class name creation, and CSS context management is freed up to only work on choosing the right class for the job.
According to the Mythical Man-Month, additional manpower added to a project often slows it down due to the exponential growth of communication channels. With Tailwind, gone is the need to enforce BEM sensibly across a codebase. No more one-off pixel value "just to match the design". No more debates on when a set of styles should be abstracted into utility classes.
Benefit Three: Tailwind is CSS on Rails. It's especially helpful when you need a Design System 'that just works!' or have a large Front-End team with few documented styling guidelines and no time to build/enforce them.
I urge you to give Tailwind CSS a try if you are currently framework shopping, or if you have a front-end project that 'just needs some style' but don't want to be stuck with 'that Bootstrap look'.
I hope I did a good enough job to convince you that Tailwind is a game-changer that every developer should consider. Next week, I will write about the downsides of using Tailwind CSS.
If you found this post interesting and haven't done so already, check out my post on creating Styling API with CSS Custom Props for an alternative solution to better styling through Design Systems.
Top comments (0)