DEV Community

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

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.

seangwright profile image
Sean G. Wright • Edited on

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.