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.
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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.