Tailwind CSS has recently earned a lot of attention in the front-end development world. I first heard about it from this tweet and after some investigation and initial hesitancy decided to give it a try. I’m now wrapping up my first deep dive using it in production code and want to share my impressions, most of which are positive.
First, some background: Tailwind CSS is a utility-based CSS library that values speed and practicality over lean, semantic markup. Think guilt-free inline styles. Depending on the scope of your project, you could conceivably develop an entire site without writing a single line of your own CSS. Tailwind is by no means the first or only utility CSS library out there, but there’s definitely been a renewed interest in that philosophy with all of the hype Tailwind is getting.
For the sake of this review, the “traditional” approach I’m comparing Tailwind to consists of writing markup in a templating language like Twig or Blade, then styling it with CSS built with Bootstrap and a preprocessor like SASS. Now let’s get into it.
Basic Usage
I highly recommend taking a few minutes to play with Tailwind’s default out-of-the-box styles before you get into configuring tailwind.js or writing your own classes. If you’re coming from a SASS or LESS mindset, your first reaction to Tailwind’s approach will likely be dismay at the sheer number of classes required for even relatively basic elements. Just look at the example on Tailwind’s own site; twelve classes on one button just to give it rounded edges and a purple border! To that I say: You’re right. Your markup will almost certainly be “uglier” than what you’re used to. But you get used to it, and the benefits are worth it — most of the time.
Immediate Benefits
So what are those benefits? The most freeing one, in my opinion, is never having to worry about changes to one element adversely affecting another tangentially-related element. Even with the most diligent front-end developer, large-scale projects using traditional styling approaches are constantly-growing Jenga towers of HTML and CSS in danger of collapsing every time an old class needs updating. Yes, BEM style exists and is a totally reasonable solution to that anxiety. But BEM always felt like more of a workaround than a best practice to me, and with BEM your stylesheet still grows as your number of templates does — a drawback not necessarily true for utility CSS.
Once you have some familiarity with the syntax and get into a flow writing out styles, you’ll notice a lot of “Wait, that’s it?” moments as you go. No more tabbing back and forth between HTML and stylesheets in your editor or waiting for preprocessors to run between page reloads. No more having to choose between your preprocessor or hot reloading. No more having to go back and check to see what you named that other element that’s kind of like this new one that maybe you can borrow some styles from or extend it or write a mixin or whatever. Just HTML, and occasional referencing of Tailwind’s (very good, for the most part) documentation.
Anecdotally, I’ve also noticed that while the average number of classes per element increases significantly, the amount of nesting necessary to achieve most layouts and functionality actually tends to decrease a bit, as every element can do double duty as a utility wrapper and a semantic tag.
This could very well be a passing trend that I come home from as soon as I need to absolutely position something or animate an SVG, but for now, I’m enjoying it immensely.
