I think the main allure is maintainability and code confidence. If you're code isn't dependent on custom "named" classes then you never have to worry about breaking something somewhere else when making a style change. How many times have you changed a class style only to realize it breaks some implementation somewhere else in your app that you now need yet another custom class for though? To your point, no it doesn't make style declaration cleaner, it makes it so you don't have CSS files 1000's of lines long with 100's of unique classes defined that have maybe 1 or 2 property differences.
I'm not a Tailwind advocate but there are legitimate use cases where the philosophy behind Tailwind makes sense. For instance when an app gets too large to maintain any reasonable sense of where classes are applied and you're able to confidently say, "making this style change will only effect this scenario". Or, you have multiple people working on separate teams changing code on the same app. Is Tailwind pointless on a marketing website? Probably. Does it make your mark-up more complex and harder to read? Yes. When you're dealing with an application with 100's of features and UI components and multiple teams though... you'll trade the time it takes to read Tailwind for not having to account for class duplication or test, and fix, your changes to an existing class breaking a different implementation in the app.
the main allure is maintainability and code confidence
Saying that something is more maintainable and at the same time more complex and difficult to read (later in the comment) is contradictory. Complexity and difficulty to read make the code more difficult to maintain. What is it?
How many times have you changed a class style only to realize it breaks some implementation somewhere else in your app that you now need yet another custom class for though?
Almost none. To be honest, I can't remember having that problem at all. Following a methodology similar to BEM (not necessarily BEM) will avoid that problem completely. If your class is something like module-component-element, you will not get name conflicts and it will be easy to know what each class represents (both in HTML and CSS).
it makes it so you don't have CSS files 1000's of lines long with 100's of unique classes defined that have maybe 1 or 2 property differences
The CSS code generated by tailwind is literally CSS files with 1000s of lines of code with unique classes with just one property. You may not see how the sausage gets made, but it gets made anyway.
Don't take me wrong. Tailwind has good things: CSS code pruning which is great, the apply directive (discouraged by the authors), cross browser support (it adds vendor prefixes)... But I wouldn't list maintainability or small code as pros. I would consider them neutral or put the in the cons column.
To your point, no it doesn't make style declaration cleaner, it makes it so you don't have CSS files 1000's of lines long with 100's of unique classes defined that have maybe 1 or 2 property differences.
And I would say that is a sign you need to learn how to use CSS, not change your tool. For one, knowing when to attach a style to a generic element type or class name as opposed to using a utility class is essential, and many people just never bother figuring this out.
That's why I think it's silly when some people pretend that tools like tailwind don't let you get around learning CSS, because you have to know CSS to use TW effectively. I hear this often as a defence when people don't want to admit that they just don't want to learn actual CSS. It shows that they don't even know what they don't know, because the only way anyone could reach a conclusion like that is by believing CSS is nothing more than knowing some property names and maybe understanding how flex works.
This is both insulting to anyone who actually takes the time to learn CSS properly, and paints a very questionable picture of those TW advocate, making it hard to take their word for anything CSS-related.
Almost none. To be honest, I can't remember having that problem at all. Following a methodology similar to BEM (not necessarily BEM) will avoid that problem completely. If your class is something like module-component-element, you will not get name conflicts and it will be easy to know what each class represents (both in HTML and CSS).
I've never liked BEM much, and tend to opt for more of an axiomatic approach to CSS, and I can confirm that I also don't usually deal with these problems. More precisely, it usually isn't a problem, because when I change a rule like "h1 { color: red; }" to "h1 { color: blue; }" it's because I want it to affect headings everywhere.
I call that consistency, and file it as a good thing in the general case.
When I'm dealing with more specific scenarios, I will usually just write more specific rules to reflect that, and tell the browser where or when I want the heading to be blue. Sometimes this even helps me catch myself when I'm using the wrong sort of element or my HTML structure is just weird, which happens relatively often when you're focusing how your page looks.
And in very special cases, adding a style attribute is always an option, if I know a change is specific to one exact situation.
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
That is to understand CSS and match elements to a style guideline: things that must move together should move together, while exceptions should be local (unless there is another general rule).
It is a very good explanation and I encourage you to write an article on it. We need more of this to be out there and we need to convince people that reasonable CSS can be short, terse and clean.
I should clarify, it makes the production code more complex and harder to read, not the source code. Yes it spits out files with 1000's of css but I don't care about minified production code's readability or complexity. I care about the source code I maintain and manage. Like I said, I'm not some tailwind advocate but it has gained traction for a reason.
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.
I think the main allure is maintainability and code confidence. If you're code isn't dependent on custom "named" classes then you never have to worry about breaking something somewhere else when making a style change. How many times have you changed a class style only to realize it breaks some implementation somewhere else in your app that you now need yet another custom class for though? To your point, no it doesn't make style declaration cleaner, it makes it so you don't have CSS files 1000's of lines long with 100's of unique classes defined that have maybe 1 or 2 property differences.
I'm not a Tailwind advocate but there are legitimate use cases where the philosophy behind Tailwind makes sense. For instance when an app gets too large to maintain any reasonable sense of where classes are applied and you're able to confidently say, "making this style change will only effect this scenario". Or, you have multiple people working on separate teams changing code on the same app. Is Tailwind pointless on a marketing website? Probably. Does it make your mark-up more complex and harder to read? Yes. When you're dealing with an application with 100's of features and UI components and multiple teams though... you'll trade the time it takes to read Tailwind for not having to account for class duplication or test, and fix, your changes to an existing class breaking a different implementation in the app.
Saying that something is more maintainable and at the same time more complex and difficult to read (later in the comment) is contradictory. Complexity and difficulty to read make the code more difficult to maintain. What is it?
Almost none. To be honest, I can't remember having that problem at all. Following a methodology similar to BEM (not necessarily BEM) will avoid that problem completely. If your class is something like module-component-element, you will not get name conflicts and it will be easy to know what each class represents (both in HTML and CSS).
The CSS code generated by tailwind is literally CSS files with 1000s of lines of code with unique classes with just one property. You may not see how the sausage gets made, but it gets made anyway.
Don't take me wrong. Tailwind has good things: CSS code pruning which is great, the apply directive (discouraged by the authors), cross browser support (it adds vendor prefixes)... But I wouldn't list maintainability or small code as pros. I would consider them neutral or put the in the cons column.
And I would say that is a sign you need to learn how to use CSS, not change your tool. For one, knowing when to attach a style to a generic element type or class name as opposed to using a utility class is essential, and many people just never bother figuring this out.
That's why I think it's silly when some people pretend that tools like tailwind don't let you get around learning CSS, because you have to know CSS to use TW effectively. I hear this often as a defence when people don't want to admit that they just don't want to learn actual CSS. It shows that they don't even know what they don't know, because the only way anyone could reach a conclusion like that is by believing CSS is nothing more than knowing some property names and maybe understanding how flex works.
This is both insulting to anyone who actually takes the time to learn CSS properly, and paints a very questionable picture of those TW advocate, making it hard to take their word for anything CSS-related.
I've never liked BEM much, and tend to opt for more of an axiomatic approach to CSS, and I can confirm that I also don't usually deal with these problems. More precisely, it usually isn't a problem, because when I change a rule like "h1 { color: red; }" to "h1 { color: blue; }" it's because I want it to affect headings everywhere.
I call that consistency, and file it as a good thing in the general case.
When I'm dealing with more specific scenarios, I will usually just write more specific rules to reflect that, and tell the browser where or when I want the heading to be blue. Sometimes this even helps me catch myself when I'm using the wrong sort of element or my HTML structure is just weird, which happens relatively often when you're focusing how your page looks.
And in very special cases, adding a
styleattribute is always an option, if I know a change is specific to one exact situation.That is to understand CSS and match elements to a style guideline: things that must move together should move together, while exceptions should be local (unless there is another general rule).
It is a very good explanation and I encourage you to write an article on it. We need more of this to be out there and we need to convince people that reasonable CSS can be short, terse and clean.
I should clarify, it makes the production code more complex and harder to read, not the source code. Yes it spits out files with 1000's of css but I don't care about minified production code's readability or complexity. I care about the source code I maintain and manage. Like I said, I'm not some tailwind advocate but it has gained traction for a reason.