The answer to virtually all of your complaints is extracted components.
Let's address your complaints one by one though:
It's WET, not DRY.
Not if you use extracted components.
You have a wrapper class you like to use a million times? Great. Extract it! Then you only have to edit it once to update everywhere. Still DRY my dude.
HTML should only concern itself with the structure of your page, not the styling of the page.
These are inextricably linked though. Ever use a modifier class to change how your component appears? Where is that going? In your HTML.
Know what modifier classes are eerily similar to? Utility classes.
For example: need to stop page scrolling when a modal is open? Rather than writing a new class to do that, just use the overflow-hidden class already at your disposal.
It's hard to read.
I totally agree! ...So use extracted components.
Now you can write your html with a simple class like card, and then go to town in your CSS with:
@apply relative p-4 rounded-sm ...;
You lose a lot of the features built into standard CSS
Not true. Again, use extracted components.
It solves a problem that doesn't exist
At this point it should be obvious the problem it's solving, but just to clarify: it makes writing CSS easier and modifying your components in a logical way. Meaning, less time writing out individual css properties and values.
You want to see an obvious problem it solves?
I want a box to fill it's container, according to you I should just write plain CSS like so:
5 lines of CSS I have to write or copy/paste from somewhere. And if I want to update the positioning to be 1rem in on each side? Now I have to update 4 lines individually.
Not with extracted components:
.box{@applyabsoluteinset-0;}
If you want better than CSS, there are already solutions.
All of the solutions you mentioned don't make writing CSS any easier. You mention CSS-in-JS solutions, but that goes against your argument that styling shouldn't be in your HTML and you mention BEM/SMACSS but that's just a writing convention.
It literally provides no value, and tons of problems.
There is massive value in efficiency. If you want to write code faster and keep your stylesheets lean, there is plenty of value in something like Tailwind.
And I say this as someone who up until 6 months ago, refused to try out utility classes for similar hesitations. But instead of writing a big long post about why I think it's useless, I gave it a try and found a way to fit it into my workflow in a way that has allowed me to speed up my development time and still create accessible codebases for new developers (extracted components still live alongside regular CSS).
BONUS: nowhere did you mention the treeshaking capabilities of tailwind. If you're managing large-scale sites with massive style guides and you care about bundlesize, that alone is a benefit of Tailwind that I'd find it hard for anyone to argue against.
As an aside:
Personally, I don't love when people use a platform like this, where lots of newcomers to our industry frequently look to for answers, voice an ~opinion~ that borders on condescension about something that they don't seem to fully understand.
It's ok to have an opinion, or prefer different tools, but if you don't like something or don't understand the value, you don't need to pull a Tucker Carlson (???) response to it.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Ever use a modifier class to change how your component appears? Where is that going? In your HTML.
Yes, I've worked places where we do this. But I've also worked places where we use Bootstrap, and they're both bad ideas as far as I'm concerned. I don't think we should use modifier classes.
Who said anything about Bootstrap? I'm also very curious what you're doing instead of using modifier classes to style variants. Are you just writing inline styles? Duplicating other class styles to create a new class just to avoid this?
I guess everything else I pointed out you don't feel like addressing? It's pretty clear to me that you aren't interested in wavering from your original "opinion" here.
Best of luck navigating this industry with that mentality.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I did, me. What I'm saying is that I've worked places where we've used Bootstrap, which uses modifier classes and does basically all the things people criticise about Tailwind. Just because I've worked somewhere that does it a particular way, and where I go along with it because it's my job, doesn't mean I approve of something. So yes, I have and still do use modifier classes, and no I don't think they're the right approach.
very curious what you're doing instead of using modifier classes to style variants
Writing semantic HTML. Where there's an absolute client requirement to do something non-semantic, then adding classes beyond the semantic, but pushing back against it.
I guess everything else I pointed out you don't feel like addressing?
Everything else you pointed out was something I (mostly) agreed with.
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 answer to virtually all of your complaints is extracted components.
Let's address your complaints one by one though:
It's WET, not DRY.
Not if you use extracted components.
You have a wrapper class you like to use a million times? Great. Extract it! Then you only have to edit it once to update everywhere. Still DRY my dude.
HTML should only concern itself with the structure of your page, not the styling of the page.
These are inextricably linked though. Ever use a modifier class to change how your component appears? Where is that going? In your HTML.
Know what modifier classes are eerily similar to? Utility classes.
For example: need to stop page scrolling when a modal is open? Rather than writing a new class to do that, just use the
overflow-hiddenclass already at your disposal.It's hard to read.
I totally agree! ...So use extracted components.
Now you can write your html with a simple class like
card, and then go to town in your CSS with:You lose a lot of the features built into standard CSS
Not true. Again, use extracted components.
It solves a problem that doesn't exist
At this point it should be obvious the problem it's solving, but just to clarify: it makes writing CSS easier and modifying your components in a logical way. Meaning, less time writing out individual css properties and values.
You want to see an obvious problem it solves?
I want a box to fill it's container, according to you I should just write plain CSS like so:
5 lines of CSS I have to write or copy/paste from somewhere. And if I want to update the positioning to be
1remin on each side? Now I have to update 4 lines individually.Not with extracted components:
If you want better than CSS, there are already solutions.
All of the solutions you mentioned don't make writing CSS any easier. You mention CSS-in-JS solutions, but that goes against your argument that styling shouldn't be in your HTML and you mention BEM/SMACSS but that's just a writing convention.
It literally provides no value, and tons of problems.
There is massive value in efficiency. If you want to write code faster and keep your stylesheets lean, there is plenty of value in something like Tailwind.
And I say this as someone who up until 6 months ago, refused to try out utility classes for similar hesitations. But instead of writing a big long post about why I think it's useless, I gave it a try and found a way to fit it into my workflow in a way that has allowed me to speed up my development time and still create accessible codebases for new developers (extracted components still live alongside regular CSS).
BONUS: nowhere did you mention the treeshaking capabilities of tailwind. If you're managing large-scale sites with massive style guides and you care about bundlesize, that alone is a benefit of Tailwind that I'd find it hard for anyone to argue against.
As an aside:
Personally, I don't love when people use a platform like this, where lots of newcomers to our industry frequently look to for answers, voice an ~opinion~ that borders on condescension about something that they don't seem to fully understand.
It's ok to have an opinion, or prefer different tools, but if you don't like something or don't understand the value, you don't need to pull a Tucker Carlson (???) response to it.
Yes, I've worked places where we do this. But I've also worked places where we use Bootstrap, and they're both bad ideas as far as I'm concerned. I don't think we should use modifier classes.
Who said anything about Bootstrap? I'm also very curious what you're doing instead of using modifier classes to style variants. Are you just writing inline styles? Duplicating other class styles to create a new class just to avoid this?
I guess everything else I pointed out you don't feel like addressing? It's pretty clear to me that you aren't interested in wavering from your original "opinion" here.
Best of luck navigating this industry with that mentality.
I did, me. What I'm saying is that I've worked places where we've used Bootstrap, which uses modifier classes and does basically all the things people criticise about Tailwind. Just because I've worked somewhere that does it a particular way, and where I go along with it because it's my job, doesn't mean I approve of something. So yes, I have and still do use modifier classes, and no I don't think they're the right approach.
Writing semantic HTML. Where there's an absolute client requirement to do something non-semantic, then adding classes beyond the semantic, but pushing back against it.
Everything else you pointed out was something I (mostly) agreed with.