By making styling more visible and flexible, and limiting cognitive load. When working with a massive component-based SaaS codebase and an immature, unstable design system, I want to see styles in the DOM template of the component where they’re being applied without having to reference several different CSS files written by different authors at different times all applying globally what they thought could be taken for granted finding myself in CSS cascade hell trying to implement something new without breaking existing legacy UIs or take on the complexity of the entire system.
Pure CSS is beautiful and I can’t wait to ditch Tailwind… later, when the design system is mature and my UI is all nice, clean components, and what a joy it will be (and so easy too) to replace all of those tailwind classes with clean, structured CSS. But honestly, if I never get there, Tailwind will be just fine.
@stephenhebert Tailwind does not resolve the problem you described. Frameworks like Angular, Vue, and React do. You can encapsulate your styles within components. Even Web Components can be used today. Even using only Sass you still can structure code well.
By making hundred different small classes used within one element, it is extremely difficult to understand the semantic and expected behavior. The code should present the logic first. Implementation is important only when you want to dive into code changes, behaviour, or the like.
Check this article from creator of TailwindCSS. link.
I’ve written a few thousand words on why traditional “semantic class names” are the reason CSS is hard to maintain, but the truth is you’re never going to believe me until you actually try it. If you can suppress the urge to retch long enough to give it a chance, I really think you’ll wonder how you ever worked with CSS any other way.
Adam Wathan, Creator of Tailwind CSS
If you guys would like to know what TailwindCSS actually do and why, it might be a good idea to get on their official website and read by yourself.
I think you looked at this syntax "bg-white dark:bg-darkNight dark:border-matteGray border-b border-grayLighter w-full flex justify-between px-2 py-3 items-center xl:hidden fixed top-0 z-20" and become a hater just because it looks ugly.
But you forgot the benefit from it:
All of these configs are very clear, when you get the hang of it you can imagine or figure out how the element looks like exactly at the same time writing html code. No need to check the class name, looking for which css file contains that class then traverse all the css attributes for that class.
And more important thing, IMHO, the visual and preciseness of those tw classes, it's defined right on that element and belongs to that element only. When working with css class, I easily fall in the trap of nested classes, it works right on this page but on the other page, someone make some hacks to modify it a little bit. Everything will end up as a mess and very difficult to find out the reason.
@ginkcode "All of these configs are very clear, when you get the hang of it you can imagine or figure out how the element looks like exactly at the same time writing html code. "
That's the most unneeded "feature." You should not read the code to determine the meaning and expected action of a particular element. Those small classes are related to one (in general) case, and later, with the combination of all of them, they create a single element with its behavior. I don't see any advantages to having 20–30+ micro CSS classes and forcing the software engineer to read and analyse the code to find out what it is and how it behaves.
"And more important thing, IMHO, the visual and preciseness of those tw classes, it's defined right on that element and belongs to that element only."
No, they are shared classes. Anything you change in one class affects all places where it is used. Single classes, like margin or font weight, used alone might be applied to some specific cases, e.g., components used only in one place. Or you're adding modifications to some old code and you don't want to change the main element's CSS class, but rather just add one style.
"Everything will end up as a mess and very difficult to find out the reason."
Properly structured and organised Sass will make everything perfectly understandable, manageable, and easy to maintain. Using 20 or more microclasses makes the code very hard to understand and manage, unnecessarily increases the HTML size, and may, in some situations, also impact the performance.
You're talking about css shared classes. TW classes are different, I never think of any developer will ever try to override TW classes. They should be out of mind.
Anyway, if you prefer to work with Sass then that's your choice and no one is against that.
TW has proven its usefulness to the community and is well received by the developers. That's why it become so popular.
You're talking about css shared classes. TW classes are different, I never think of any developer will ever try to override TW classes. They should be out of mind.
Aren't TW classes shared? Is overriding an unnecessary and never wanted need?
Anyway, if you prefer to work with Sass then that's your choice and no one is against that.
Sass has nothing to do with TW. Sass organising your styles and working on them.
TW has proven its usefulness to the community and is well received by the developers. That's why it become so popular.
Popularity doesn't mean something is good. This has never been the case.
I'd be happy if you could provide a table with 2 columns: [Challange] [How TW resolved it] in the below post.
By making styling more visible and flexible, and limiting cognitive load. When working with a massive component-based SaaS codebase and an immature, unstable design system, I want to see styles in the DOM template of the component where they’re being applied without having to reference several different CSS files written by different authors at different times all applying globally what they thought could be taken for granted finding myself in CSS cascade hell trying to implement something new without breaking existing legacy UIs or take on the complexity of the entire system.
Pure CSS is beautiful and I can’t wait to ditch Tailwind… later, when the design system is mature and my UI is all nice, clean components, and what a joy it will be (and so easy too) to replace all of those tailwind classes with clean, structured CSS. But honestly, if I never get there, Tailwind will be just fine.
@stephenhebert Tailwind does not resolve the problem you described. Frameworks like Angular, Vue, and React do. You can encapsulate your styles within components. Even Web Components can be used today. Even using only Sass you still can structure code well.
By making hundred different small classes used within one element, it is extremely difficult to understand the semantic and expected behavior. The code should present the logic first. Implementation is important only when you want to dive into code changes, behaviour, or the like.
@stephenhebert , Tailwind does not decrease cognitive load. It does the exact opposite. I want to see less code, and more business.
Check this article from creator of TailwindCSS.
link.
If you guys would like to know what TailwindCSS actually do and why, it might be a good idea to get on their official website and read by yourself.
The idea behind Tailwind described by inventor isn't convenient to me. Let's move that discussion to some other relevant post.
I think you looked at this syntax
"bg-white dark:bg-darkNight dark:border-matteGray border-b border-grayLighter w-full flex justify-between px-2 py-3 items-center xl:hidden fixed top-0 z-20"and become a hater just because it looks ugly.But you forgot the benefit from it:
@ginkcode "All of these configs are very clear, when you get the hang of it you can imagine or figure out how the element looks like exactly at the same time writing html code. "
That's the most unneeded "feature." You should not read the code to determine the meaning and expected action of a particular element. Those small classes are related to one (in general) case, and later, with the combination of all of them, they create a single element with its behavior. I don't see any advantages to having 20–30+ micro CSS classes and forcing the software engineer to read and analyse the code to find out what it is and how it behaves.
"And more important thing, IMHO, the visual and preciseness of those tw classes, it's defined right on that element and belongs to that element only."
No, they are shared classes. Anything you change in one class affects all places where it is used. Single classes, like margin or font weight, used alone might be applied to some specific cases, e.g., components used only in one place. Or you're adding modifications to some old code and you don't want to change the main element's CSS class, but rather just add one style.
"Everything will end up as a mess and very difficult to find out the reason."
Properly structured and organised Sass will make everything perfectly understandable, manageable, and easy to maintain. Using 20 or more microclasses makes the code very hard to understand and manage, unnecessarily increases the HTML size, and may, in some situations, also impact the performance.
You're talking about css shared classes. TW classes are different, I never think of any developer will ever try to override TW classes. They should be out of mind.
Anyway, if you prefer to work with Sass then that's your choice and no one is against that.
TW has proven its usefulness to the community and is well received by the developers. That's why it become so popular.
@ginkcode
Aren't TW classes shared? Is overriding an unnecessary and never wanted need?
Sass has nothing to do with TW. Sass organising your styles and working on them.
Popularity doesn't mean something is good. This has never been the case.
I'd be happy if you could provide a table with 2 columns: [Challange] [How TW resolved it] in the below post.
I'd propose to move topic-related discussion to: dev.to/cezarytomczyk/tailwind-over...