Two cheers for Tailwind

General note: This site’s appearance, configuration, hosting, and other basic considerations will change over time. As a result, certain content on this page could be at variance with what you’re currently seeing on the site, but the two were consistent when this post originally appeared.

A couple of weekends ago, I tweeted a question for the web devs among my few but greatly appreciated Twitter followers. It was the Saturday between Christmas and New Year’s, so I figured I’d be fortunate if I got a handful of responses.

Reading about @tailwindcss and other #atomicCSS approaches (@tachyons_css, @basscss , etc.). They seem aimed at the multi-project, multi-dev use case. But what if it’s just one personal Web site with one maintainer (HTML and CSS)? Worth it then?
5:25 PM • December 28, 2019 (UTC)

Then it got retweeted by the Tailwind CSS Twitter account and, well, my phone was pretty actively “bink”-ing at me for a few hours thereafter.

Tens of thousands of “impressions” and a few dozen mostly enthusiastic answers later, I had a pretty clear, albeit obviously biased, direction . . .

Yeah, man, go for it.

So I spent my spare time during the next few days doing precisely that on a branch of my site and, during the first afternoon of 2020, merged that branch into Master and pushed it to Netlify:

Another holiday, another site spruce-up. Decided to go the @tailwindcss route, as recommended by so many this past weekend — and, while at it, also made long-overdue changes to improve readability (I hope). Opinions welcome. Be nice. 😄 brycewray.com
10:09 PM • January 1, 2020 (UTC)

Not a purist

Although I still haven’t quite gotten used to the appearance of this utility-first approach to CSS in my HTML . . .

<div class="absolute bottom-0 text-shadow-titles sm:px-20 md:px-30 lg:px-36 pt-6 gradient-titles w-full min-w-full">

. . .  i.e., as opposed to previous styling for that same div:

<div class="background-hero-title-block-fit">

. . .  the truth is that, apparently, I’ve been writing at least some form of utility-first CSS well before it received that name and certainly well before the ongoing industry infighting over whether it’s the Greatest Thing Evah, an unforgivable sin against the holy of holies, or something in between.

In 2002, I began using CSS for the first time, but this was before CSS Zen Garden — of which, to be honest, I never learned until many years later — and those whom it inspired carved out what was supposed to be a hard line between content (HTML) and that content’s appearance (CSS). No, I blithely was occasionally doing nasty things like the following when I just didn’t want to go through the rigamarole.

First, the CSS:

.ctr {
	text-align: center;
}

h2.h2big {
	font-size: 3rem;
}

.darkBlue {
	color: #00000a1;
}

And then the HTML:

<h2 class="ctr h2big darkBlue">
	My big not-H1 headline that I want to be dark blue
</h2>

What I’m saying, then, is that any concerns I have about this approach definitely are not from the standpoint of being a warrior for purity. On this issue, I have zero credibility in that regard.

Oh, the utility

I guess what still mainly bugs me is the whole idea of whether, specifically for an SSG-built site like mine that depends so heavily on a small number of templates, I might not be better off just going back to a less utilitarian method. Am I really gaining anything from this build-the-appearance-one-Lego-block-at-a-time approach? Would I be wiser just to revert to the way I was doing it before?

By the way: no matter which way I go, a reversion to my previous workflow probably wouldn’t mean going back to Sass/SCSS, which I jettisoned in the transition to utility-first. To learn how to use Tailwind CSS, I also had to learn about using PostCSS. It’s clear that, even I do go back to a less utilitarian approach, PostCSS and its plugins can do everything, and more, for which I used Sass/SCSS. In fact, what PostCSS enables is pretty frickin’ amazing. Just being able to take what starts out in dev mode as 2.4 MB of CSS (some of which is related to using web fonts, I should note in all fairness) and end up with it in production mode at only about 7 K is impressive, to put it mildly.

We shall see — as usual

As I observed near the end of my last post, this site’s Eleventy/webpack combo gives me a solid foundation on which to build. And, on the subject I’ve discussed here today, it further shows how easily I can try new stuff.

. . . Or not.

One aspect I have to keep in mind is, as I often mention in these posts, my wish to stay current with whatever New Hotness exists in web dev. Mind you, I won’t adopt it all, but I do want to know about it. The question I must now resolve regarding utility-first CSS is whether I can know enough about it without actually using it.

That remains TBD.

Finally, here are the best from among the many articles I’ve been reading (often, several times) recently while considering all this stuff:

• “CSS Utility Classes and ‘Separation of Concerns’” by Adam Wathan, the creator of Tailwind CSS.
• “In Defense of Utility-first CSS” by Sarah Dayan.
• “A Year of Utility Classes” by Michelle Barker.
• “The Perils of Functional CSS” by Jay Freestone.
• “Utility First and CSS Components: A Reconciliation” by Régis Philibert.
• “Use Tailwind or Roll Your Own CSS Utility Library?” by Oliver Williams.
• “In Defense of Functional CSS” by Mike Crittenden.
• “Why I Haven’t Jumped on the Tailwind CSS Bandwagon” by Angie Herrera.

Update, 2020-01-18

After a few days of mulling this over as well as re-reading a lot of stuff about what ordinary CSS can do these days, especially in league with PostCSS and the appropriate set of PostCSS plugins, I concluded I’d return to CSS Grid.¹

However, as I hinted above would be the case were I to eschew the utility-first approach, I opted not to return to Sass/SCSS.

Why?

Because I wanted to start doing CSS the right way, so to speak, rather than continuing to use the shortcuts in Sass/SCSS methods. This is not out of any masochistic tendencies (I think), but because “regular” CSS, and non-obsolete browsers’ support for it, is getting better all the time and that’s where the action is.

I won’t try to tell you that it was easy to take my previous SCSS and convert it to CSS that PostCSS can transpile to browser-friendly CSS. Quite frankly, using Sass/SCSS left me with some bad habits, like nesting media queries inside selectors. And even if somewhere there is a PostCSS way to get around things like that: well, I don’t care, now.²

Don’t get me wrong. I do understand that there definitely are cases to be made for utility-based CSS, especially — as I tweeted back on December 28 — for multi-dev shops. I just don’t believe my little one-man, one-approver website qualifies as a good example of such a case.

And, more to the point: I just like this way better and, unlike so many other things in my life, this is one situation where I get to make the final call.