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.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.