DEV Community

Discussion on: Is the Tailwind approach a big step forward for CSS or just-yet-another-thing?

Collapse
 
seangwright profile image
Sean G. Wright

My comment in Nick Taylor's post gives some background on what problems TailwindCSS tries to solve (spoiler! it's not trying to be the solution for every site/application).

Adam Wathan, the maintainer of TailwindCSS, wrote an article a couple years ago about the differences in CSS architecture that exist between traditional approaches (BEM, SMACSS) and atomic/utility approaches.

Here's that article: adamwathan.me/css-utility-classes-...

I recommend everyone read it.

Adam doesn't declare that one approach is bad and another is good. Instead he provides insight into what the constraints are of each and what use-cases each might be good for.

In the end he argues that most of the sites/apps he works on benefit from the approach provided by TailwindCSS and other similar libraries (Bulma, Tachyons, even Bootstrap's utility classes).

I think understanding why we should use TailwindCSS is as important (or more) as asking the question "does Tailwind make me more productive?"

And yes, I like TailwindCSS because it fits the type of work that I find myself regularly doing.

I think the key thought in the blog post from Adam Wathan (that I linked to in my other comment) is this (emphasis is Adam's):

The reason I call the approach I take to CSS utility-first is because I try to build everything I can out of utilities, and only extract repeating patterns as they emerge.

  • Naming things is hard, so don't force yourself to name things that don't deserve names yet!
  • Componentization is the process of identifying and codifying patterns of behavior, so don't componentize CSS when you don't even have a pattern yet!
  • Utility classes constrain by defining the limited set of options available, which is easier to reason about the next time you try to style a <div>, compared to the entirety of CSS. (We are freed to be creative through our constraints).
Collapse
 
etienneburdet profile image
Etienne Burdet

Thanks for sharing!
I do agry on not componentizing/abstracting too early and I have been a huge user of bootstrap utility-class… only to move away from it all over again.

When you have to maintain your app, you definitely don't want to be chasing if every single spacing utility has been changed correctly. A coherent system of named components greatly helps in that.

Collapse
 
seangwright profile image
Sean G. Wright • Edited

That's a great point and an issue I've run into myself.

The Pros of this approach are also the Cons! 😁

If I use these utility classes to style my markup, then I can change markup and classes in one part of the app without worrying about regressions somewhere else.

The utility class approach is resistant to unintended changes, which is a great feature 💪!

However, if I want to make the same change across the entire app, I'm going to have to do that manually because the utility class approach is resistant to intended changes, which means more work for me ☹.

So here's a question worth considering - what's more important to you, preventing regressions or refactoring quickly 🤔?

The answer to this question needs to be balanced with the other pros/cons of utility based classes already detailed.

One thing I've found helps mitigate the refactoring cost of utility based classes is componentization, not at the CSS level, but at the HTML level.

Client-side JavaScript frameworks (and even some server-side templating languages) excel at this. They are able to group blocks of reusable HTML into a 'component', which means some app-wide changes can be made in a single location.

Collapse
 
mikaelgramont profile image
Mikael Gramont

Thanks for bringing up the original article again. I read it back then, and seeing how popular Tailwind has become, it's good to see what prompted it in the first place.
Going down the article, you can't really help but be convinced that he's on to something.