The emphasis is itself wrong, because it fools the developer that writing modular CSS is easier. If you're creating the same CSS container for every small stuff, utility first CSS is a much better solution. There's a reason why Utility-first CSS has had a great uptake at big companies (e.g, Github, Adobe..), it's because they know how big of a mess CSS becomes at large codebases.
But, you're point is not wrong. Replacing classes can become a PITA and verbosity is just ugly. Luckily, you can always create classes and write custom CSS. I don't agree with Tailwind's approach, where you never have to write CSS. It's often a much better solution (e.g, paragraph spacing).
The answer lies somewhere in the middle. In most cases, utility classes would do the job and you won't miss much or anger the future developer. For things like buttons, links, paragraph spacing, it makes sense to have some sort of base styling.
Have to agree with this. There are a few points in the original comment that I take issue with:
Updating FE components: This seems to be a common complaint but I've rarely seen a situation where anyone actually wants to do this. "Well with CSS, I make a change in one place, and update the whole site." This is not only dangerous, because if updating the "whole site" is so difficult update, this inevitably leads to unintended consequences of things changing that you didn't expect. Sure changing a color is one thing. But how often is this even happening? The "difficulty" and intentionality of changing the markup is a feature, not a bug.
Rendering the markup: This is a bit of red herring. The rendered markup is endlessly changing and growing in an app. Massive amounts of data in a table to thousands of posts on a blog. The names of a few classes is orders of magnitude smaller than all the JS, CDN's, HD images, API data, etc... (not to mention the massive amounts of CSS) that often load in milliseconds already.
That all said, I don't think I agree with "There's 'nothing' wrong with inline-styles", there is plenty wrong. But I don't think they're wrong for the sake of it. And when used sparingly (read: as minimally as possible) it sure beats adding adding to a constantly growing stylesheet for one-to-two random use-cases.
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.
The emphasis is itself wrong, because it fools the developer that writing modular CSS is easier. If you're creating the same CSS container for every small stuff, utility first CSS is a much better solution. There's a reason why Utility-first CSS has had a great uptake at big companies (e.g, Github, Adobe..), it's because they know how big of a mess CSS becomes at large codebases.
But, you're point is not wrong. Replacing classes can become a PITA and verbosity is just ugly. Luckily, you can always create classes and write custom CSS. I don't agree with Tailwind's approach, where you never have to write CSS. It's often a much better solution (e.g, paragraph spacing).
The answer lies somewhere in the middle. In most cases, utility classes would do the job and you won't miss much or anger the future developer. For things like buttons, links, paragraph spacing, it makes sense to have some sort of base styling.
Have to agree with this. There are a few points in the original comment that I take issue with:
Updating FE components: This seems to be a common complaint but I've rarely seen a situation where anyone actually wants to do this. "Well with CSS, I make a change in one place, and update the whole site." This is not only dangerous, because if updating the "whole site" is so difficult update, this inevitably leads to unintended consequences of things changing that you didn't expect. Sure changing a color is one thing. But how often is this even happening? The "difficulty" and intentionality of changing the markup is a feature, not a bug.
Rendering the markup: This is a bit of red herring. The rendered markup is endlessly changing and growing in an app. Massive amounts of data in a table to thousands of posts on a blog. The names of a few classes is orders of magnitude smaller than all the JS, CDN's, HD images, API data, etc... (not to mention the massive amounts of CSS) that often load in milliseconds already.
That all said, I don't think I agree with "There's 'nothing' wrong with inline-styles", there is plenty wrong. But I don't think they're wrong for the sake of it. And when used sparingly (read: as minimally as possible) it sure beats adding adding to a constantly growing stylesheet for one-to-two random use-cases.