Note: This post also appears on dev.to and was the subject of a Hacker News thread.
Earlier this week, a blog post introduced version 3.2 of the popular Tailwind CSS styling framework.
The “absolutely massive amount of new stuff” the post trumpeted includes:
- Multiple config files in one project using
- Browser-support-based styling with
- ARIA attribute variants
- Data attribute variants
- Max-width and dynamic breakpoints
- Dynamic variants with
peersupport using variant modifiers
- Container queries
. . . the details of which all sound impressive, to be sure. However, as I read about them, I was reminded of something I wrote near the end of the “Should you adopt Tailwind 3?” piece I did back in January for the Stackbit blog:
Because of Tailwind’s need to stay not simply relevant but also popular, the project is particularly vulnerable to the dangers of feature creep. . . . [R]emember that the idea behind Tailwind, like every other utility-first CSS framework, is to make styling easier, especially for front-end developers who dislike getting under CSS’s hood. The more capabilities that get added to Tailwind, the more complex Tailwind becomes. It may not yet be near a tipping point, but that’s a danger for which the Tailwind team will have to be on the lookout.1
That was nine months ago. Although I surely wasn’t expecting to be proven right this soon, all the new features in this v3.2 release of Tailwind, especially on top of the many other additions to Tailwind over the last two years in particular, add up to a project that now does seem, uh, a bit much.
I’ll cut to the chase for all the aforementioned “front-end developers who dislike getting under CSS’s hood”2 . . .
The more features that get added to Tailwind, the more you have to know about CSS before you can use those features. Right? So why not just bite the bullet and learn to use CSS without the additional tooling (and weird, often lengthy additions to your HTML) that Tailwind and other utility-first styling frameworks require?3
Update, 2022-10-24: The Tailwind fans who responded to this article in the aforementioned Hacker News thread were especially annoyed by one phrase in that previous paragraph — because they took it out of context. I didn’t say Tailwind users don’t know how to use CSS, and I didn’t say that using Tailwind was an alternative to learning CSS. What I did say was (and I’ll color-code the intended meaning): “So why not just bite the bullet and learn to use CSS without the additional tooling (and weird, often lengthy additions to your HTML) that Tailwind and other utility-first styling frameworks require?”
If that’s not clear enough for anyone, I apologize that I can’t further clarify it. (And, may I note, the “you’re ugly and your mother dresses you funny”-ish tone that a few of the HN responders chose to use didn’t do them, or Tailwind’s cause, any favors.)
That said: if you insist on using Tailwind because you utterly can’t bear to deal with vanilla CSS (although it’s not really all that vanilla anymore), Tailwind v3.2 provides quite a bit more to cram into your ditty bag of styling powers. You’ll have to decide when it reaches that inflection point where its use consumes more time and brainpower than it saves.
This includes a few edits for this site’s style, as opposed to how it appeared both in the original form on the Stackbit blog and its contractually required re-publication here. ↩︎
And those who manage them, given that Tailwind is especially popular as a way of enforcing styles among corporate development teams — where CSS expertise can vary widely. ↩︎
For this site, I’ve used Tailwind off-and-on over the years, but kept returning to Sass/SCSS as a more comfortable, bullet-proof styling method vs. what utility-first frameworks entail. (Then again, I’ve been working “under CSS’s hood” for 20 years, so there’s that.) ↩︎