There was a time when not having css and html completely separate was considered sacrilege. And having html in javascript would have been a mortal sin.
Eons ago I was at a job where we dynamically generated css on the server (php in that project). Anyone would have said: what about separation of concerns? Now everyone says it is best practice to have components with css, html and (gasp) Javascript all in one unit, because someone, for ex. Facebook said it (React). And the truth is it is very useful, and it is another way to structure frontend code.
My point is: it is a spectrum and it can be useful to change the styling right there in the browser inspector. That works with tailwind the same as css. And with components, you can hide the repetition, although the browser will still have the repeated classes. Is this better than having css on another file with maybe some unused classes? I have done both and I can see each has pros and cons.
The thing is, they were never really separate. The source files were separated, sure, but the way 90% of the world did CSS, there were hidden abstractions relating the class definitions in the .css file and the DOM structure in the .html that weren't documented anywhere.
Eons ago I was at a job where we dynamically generated css on the server (php in that project). Anyone would have said: what about separation of concerns? Now everyone says it is best practice to have components with css, html and (gasp) Javascript all in one unit, because someone, for ex. Facebook said it (React). And the truth is it is very useful, and it is another way to structure frontend code.
My point is: it is a spectrum and it can be useful to change the styling right there in the browser inspector. That works with tailwind the same as css. And with components, you can hide the repetition, although the browser will still have the repeated classes. Is this better than having css on another file with maybe some unused classes? I have done both and I can see each has pros and cons.