Tailwind CSS v3.2: revisiting my “feature creep” warning

Note: This also 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 @config
• Browser-support-based styling with supports-*
• ARIA attribute variants
• Data attribute variants
• Max-width and dynamic breakpoints
• Dynamic group-* and peer-* variants
• Dynamic variants with matchVariant
• Nested group and multiple peer support 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.¹

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”² . . .

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?³

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.

1. This includes a few edits for my site's style, as opposed to how it appeared both in the original form on the Stackbit blog and its contractually required re-publication on my site. ↩

2. 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. ↩

3. For my own 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.) ↩