Professional web developer and hobbyist programmer from the Welsh Marches. I'm particularly interested in performance, accessibility, and reducing carbon emissions from software.
Inline styles and utility classes are all very well until you need to update how something looks. Then you have to go through every page in turn and change the classes / styles on each individual element. When I was first learning about CSS (not that long ago), the main thing that was emphasised as an advantage of the language was the separation of styling from content.
To me, frameworks full of utility classes seem to be working against this and creating a nightmare for the future developer who has to change the way multiple components look. I can see the attraction of working with inline styling to quickly prototype a page, but it just looks like several steps backwards in terms of future maintainability.
Also, and as an aside: Surely utility class CSS is less efficient to parse for the browser? I can not imagine that having half a dozen classes on each element will not cause some form of slowdown on lower-powered devices. It might be a small difference, but I would like to see the load time of an identical page built using Tailwind and a more traditional CSS architecture.
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.
Inline styles and utility classes are all very well until you need to update how something looks. Then you have to go through every page in turn and change the classes / styles on each individual element. When I was first learning about CSS (not that long ago), the main thing that was emphasised as an advantage of the language was the separation of styling from content.
To me, frameworks full of utility classes seem to be working against this and creating a nightmare for the future developer who has to change the way multiple components look. I can see the attraction of working with inline styling to quickly prototype a page, but it just looks like several steps backwards in terms of future maintainability.
Also, and as an aside: Surely utility class CSS is less efficient to parse for the browser? I can not imagine that having half a dozen classes on each element will not cause some form of slowdown on lower-powered devices. It might be a small difference, but I would like to see the load time of an identical page built using Tailwind and a more traditional CSS architecture.
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.