What about if you're using Tailwind with some framework like React when you're building components and use Tailwind in those components? I mean, instead of replacing 123 occurrences 'blue-color' you just replace it in one place, in the button component.
After all, is Tailwind just a replacer for simplifying CSS?
I'm not defending Tailwind. I know what it is, but I've never use it. Thank you for your article (like you see from other comments [still valuable] it's controversial) but while I was reading I wondered if all disadvantages described in the article are in context of web development without frameworks like react? Because Tailwind with React could be just a replacer for more difficult CSS?
That is a good point, and in theory, that could work. I don't think that when the rubber hits the road, though, it will.
A really well organized React/Vue project will probably be like that. You have a roughly 1-to-1 ratio of "components" to "css classes". You style only in "dumb components" (i.e., stateless, takes only props), and if it's not "one className entry per component", it's at least really close.
It eliminates many of the problems I've pointed out about code-reuse, and having to change class names in multiple places.
But it doesn't eliminate the problems with debugging. If you try to inspect an element in the browser - that is, after it's no longer a component, and now lives as part of the DOM, you can't really identify what the component is by class anymore. It makes it harder to identify the root cause of the bug, which increases the Mean Time To Repair.
It also doesn't eliminate the problems with having to learn new Tailwind syntax, with prioritization (if you were to give an element "h-12 h-8", or "h-8 h-12" which height would apply first... and how would you know unless you looked at Tailwind's sourcecode to see what got defined last?)
And it certainly doesn't account for the scenario when the React or Vue app you're working with doesn't have a very "atomic/molecular/organism" structure at all - but is a mishmash of big components, small components, components that depend on Vuex, components that have props reassigned to internal state which on-change run a callback prop... (Ugh!)
What I do think might be useful is using something like the Twind library to rapidly prototype what you want your final CSS to look like, but then taking the CSS outputted by Twind, copying it from the browser inspection, and plopping it right back in to something more long-term like emotion/css.
How far down do you go with turning things into components though?
For example, imagine creating a very simple alert modal component. This contains a message, and a button. Now, I've done this exact thing, and the button is just an HTML <button>. I could embed a button component into it instead to mitigate the problems of Tailwind, but that seems like it's going too far in the direction of breaking things into the smallest possible parts. There's a point at which something becomes too small to separate out into it's own component/class/modules/etc. There's a balance between making the code readable and logical, and also ensuring that it's comprehensible by the human who is managing it.
Should the modal text be its own component too, as it contains styles very specific to a modal. It needs to be re-used across all of the other modals (prompts, confirmations, password queries, etc), and we want to avoid the need to be making multiple find/replace changes that Tailwind might force us to make otherwise.
Tailwind would allow us to do this in a more sensible manner, but it's not generally how TW projects appear to be done the majority of the time (going from the numerous articles and code examples in Git repos), and it's something that was already very much possible in vanilla CSS, let alone the many pre and post-processors for CSS that have existed and been in use for many, many years successfully.
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.
What about if you're using Tailwind with some framework like React when you're building components and use Tailwind in those components? I mean, instead of replacing 123 occurrences 'blue-color' you just replace it in one place, in the button component.
After all, is Tailwind just a replacer for simplifying CSS?
I'm not defending Tailwind. I know what it is, but I've never use it. Thank you for your article (like you see from other comments [still valuable] it's controversial) but while I was reading I wondered if all disadvantages described in the article are in context of web development without frameworks like react? Because Tailwind with React could be just a replacer for more difficult CSS?
That is a good point, and in theory, that could work. I don't think that when the rubber hits the road, though, it will.
A really well organized React/Vue project will probably be like that. You have a roughly 1-to-1 ratio of "components" to "css classes". You style only in "dumb components" (i.e., stateless, takes only props), and if it's not "one className entry per component", it's at least really close.
It eliminates many of the problems I've pointed out about code-reuse, and having to change class names in multiple places.
But it doesn't eliminate the problems with debugging. If you try to inspect an element in the browser - that is, after it's no longer a component, and now lives as part of the DOM, you can't really identify what the component is by class anymore. It makes it harder to identify the root cause of the bug, which increases the Mean Time To Repair.
It also doesn't eliminate the problems with having to learn new Tailwind syntax, with prioritization (if you were to give an element "h-12 h-8", or "h-8 h-12" which height would apply first... and how would you know unless you looked at Tailwind's sourcecode to see what got defined last?)
And it certainly doesn't account for the scenario when the React or Vue app you're working with doesn't have a very "atomic/molecular/organism" structure at all - but is a mishmash of big components, small components, components that depend on Vuex, components that have props reassigned to internal state which on-change run a callback prop... (Ugh!)
What I do think might be useful is using something like the Twind library to rapidly prototype what you want your final CSS to look like, but then taking the CSS outputted by Twind, copying it from the browser inspection, and plopping it right back in to something more long-term like emotion/css.
How far down do you go with turning things into components though?
For example, imagine creating a very simple alert modal component. This contains a message, and a button. Now, I've done this exact thing, and the button is just an HTML
<button>. I could embed a button component into it instead to mitigate the problems of Tailwind, but that seems like it's going too far in the direction of breaking things into the smallest possible parts. There's a point at which something becomes too small to separate out into it's own component/class/modules/etc. There's a balance between making the code readable and logical, and also ensuring that it's comprehensible by the human who is managing it.Should the modal text be its own component too, as it contains styles very specific to a modal. It needs to be re-used across all of the other modals (prompts, confirmations, password queries, etc), and we want to avoid the need to be making multiple find/replace changes that Tailwind might force us to make otherwise.
Tailwind would allow us to do this in a more sensible manner, but it's not generally how TW projects appear to be done the majority of the time (going from the numerous articles and code examples in Git repos), and it's something that was already very much possible in vanilla CSS, let alone the many pre and post-processors for CSS that have existed and been in use for many, many years successfully.