While following YouTube tutorials on frameworks such as Vue.js, I’d often find that the presenter was using Tailwind CSS. Of course, the tutorial focus wasn’t on styling, but it seemed to me that Tailwind was worth a deeper dive. Now I’ve had the chance to do that.
This isn’t a full review of Tailwind, let alone a tutorial – just some thoughts and opinions. Bear in mind that I’m primarily a PHP developer, although I’ve recently acquired a keen interest in using Alpine JS to spice up the web front end. So the majority of my pages are server-side rendered, with some styling changes applied dynamically by JS.
It took me a while to understand how to use Tailwind in a conventional web project. Although there is a CDN version, it’s intended only for experimentation, and they even label it “Play CDN”. The only other alternative appeared to be to use npm to install and control Tailwind, which (wrongly) led me to the conclusion that it was designed for use with a compiled framework such as Vue.js.
Eventually, though, I found and followed the instructions to install and use the Tailwind CLI without Node.js. I did this in the Linux container on my Chromebook, where I use VS Code, and to be fair, it was pretty straightforward. As a note, the VS Code extension for Tailwind is well worth installing, too.
Tailwind is a huge library of low-level CSS classes – almost all the classes contain just one declaration. So the Tailwind class ‘block’ is simply ‘display:block’, and Tailwind class ‘p-1’ is just ‘padding: 0.25rem’. Incidentally, this is why the CDN version weighs in at 111KB – all those classes add up.
Because the classes are so low-level, you have to combine them on each element. Here’s a typical example.
<h4 class="font-bold mt-12 pb-2 border-b border-gray-200">
I’ll be honest, I don’t like this much. It isn’t far removed from using inline styles, and poses a real risk to reuse. If I have five or six h4 elements on a page, with this approach, the chances are that I’ll get one of them slightly wrong; and if they all need changing to a different shade of grey, that’s more work than I want.
To counter this, Tailwind has an @apply directive, that can be used to map a conventional CSS selector to a list of Tailwind classes.
h4 {
@apply font-bold mt-12 pb-2 border-b border-gray-200;
}
OK, this answers the reuse question, but it’s a bit of a hybrid that dilutes the Tailwind approach, and in fact the Tailwind docs argue that you should avoid it wherever possible. For me, I would just use standard CSS in this situation anyway.
So I’ve already seen enough to tell me that I won’t be using Tailwind, but what features did I like?
As you add classes to your HTML, Tailwind generates a CSS file that exactly matches. There are no redundant classes, no awkwardly named classes, and there’s no risk of conflicting rules. I recognise all three of these situations.
I also quite liked the Tailwind approach to responsive styling, using a simple modifier on a class to have it apply only at a given breakpoint. So using an example from the docs:
<!-- Width of 16 by default, 32 on medium screens, and 48 on large screens -->
<img class="w-16 md:w-32 lg:w-48" src="...">
I’ve ended up wondering if Tailwind is best for people who prefer not to get their hands dirty with CSS, and for whom the busy HTML class lists are not an issue.
And finally, I do have one use case where I might just get a benefit from Tailwind. If I’m mocking up a page and don’t want to go to the effort of defining my own CSS rules, Tailwind does have an advantage over inline styles. But that’s as far as I would go with it. Otherwise, it’s a sledgehammer / walnut situation as far as I’m concerned.