Here is the problem I have with Tailwind: now, every one of your h2 tags now have 10 classes so they all look the same. If you have to create another h2, how do you know you won't forget a class? Second question: can you still use tailwind to target all children of a div, for example? What would be equivalent of, say: All direct children of a div: div > * { color: red} All children that are not the first child: .flow > * + * { margin-bottom: 1rem }
anything like a button or a card component or bigger should be extracted as a single utility react class. I don't like the concept of using @apply to self-define and combine css classes.
You are saying that one of the things, why you like Tailwind, is that it comes with some default setup, whereas when using vanilla CSS, you would have to set it all up by yourself. This argument is silly, in my opinion, because in real life, most of the devs use premade boilerplates (created by them or their team) that match the theme of their company or the style in which they like to work on their personal projects. Other question. How do you maintain big projects that use tailwind?
Fair point Ozi on the defaults, it's not a perfect solution for all scenarios I agree. The big projects maintenance question is a good one too, there are a lot of companies using it, so seems possible, but what effort involved I don't know. Adam W argues it's easier to come back to a site after x number of years and maintain it using tailwind that if it had a custom design system. That part sounds fair to me. Thanks for the feedback - Cheers Mark 🙂
My opinion: That is good, BUT for the smal projects where you dont have time to do a custom CSS (or SCSS etc.) and manage responsive etc. Because, on the big projects, with a complicated HTML structures etc., we will be lost with: - repetitions of class names - super long class attribute values We will end up adding our custom classnames too for customizing some elements, because tailwind can not do everything for us.. And adding a lot of elements on the HTML (attributes etc.) will affect the loading of the page, because "more DOM characters/lines/elements to read => more loading time", Lighthouse dont like it for exemple..
i hate frameworks but tailwind is one of the ugliest ones i know. and i'm a person who uses utility classes a lot. they have a place and a purpose but when everything is a utility class what should have been easy becomes difficult. even the ready made components from headlessui are difficult to setup and adapt for any purpose that's slightly outside of what the component was designed for. yes, you can configure and extend every minute detail of tailwind but i think most people just want a tool that works, not something that needs hours to setups and then go back and tweak. and this is on a good day, when the designer works with you, not against you. and then there's plugins and libraries that extend tailwind itself which brings another config file and another documentation page on top of all the others. no wonder project take longer than ever to finish.
![Kumamoto Masters Japan 2024 | Gregoria Mariska Tunjung (INA) [5] vs. Akane Yamaguchi (JPN) [2] | F](http://i.ytimg.com/vi/EIjZybhsWqA/mqdefault.jpg)
Here is the problem I have with Tailwind: now, every one of your h2 tags now have 10 classes so they all look the same. If you have to create another h2, how do you know you won't forget a class?
Second question: can you still use tailwind to target all children of a div, for example? What would be equivalent of, say:
All direct children of a div:
div > * { color: red}
All children that are not the first child:
.flow > * + * { margin-bottom: 1rem }
True those descender selectors we would not use in Tailwind so it does get verbose for sure.
This makes for a good argument that Tailwind shouldn't be a complete replacement for vanilla CSS. However, they can be used together.
anything like a button or a card component or bigger should be extracted as a single utility react class. I don't like the concept of using @apply to self-define and combine css classes.
Cheers for this.
All good 🙂 Cheers Mark
You are saying that one of the things, why you like Tailwind, is that it comes with some default setup, whereas when using vanilla CSS, you would have to set it all up by yourself. This argument is silly, in my opinion, because in real life, most of the devs use premade boilerplates (created by them or their team) that match the theme of their company or the style in which they like to work on their personal projects.
Other question. How do you maintain big projects that use tailwind?
Fair point Ozi on the defaults, it's not a perfect solution for all scenarios I agree. The big projects maintenance question is a good one too, there are a lot of companies using it, so seems possible, but what effort involved I don't know. Adam W argues it's easier to come back to a site after x number of years and maintain it using tailwind that if it had a custom design system. That part sounds fair to me. Thanks for the feedback - Cheers Mark 🙂
My opinion:
That is good, BUT for the smal projects where you dont have time to do a custom CSS (or SCSS etc.) and manage responsive etc.
Because, on the big projects, with a complicated HTML structures etc., we will be lost with:
- repetitions of class names
- super long class attribute values
We will end up adding our custom classnames too for customizing some elements, because tailwind can not do everything for us..
And adding a lot of elements on the HTML (attributes etc.) will affect the loading of the page, because "more DOM characters/lines/elements to read => more loading time", Lighthouse dont like it for exemple..
Thanks Soso - these are good points for sure. I agree for small projects seems a great fit. Larger ones there is lots of debate on yep :-) Cheers Mark
this is completely unnecessary if you use the bem methodology. everything has already been invented a long time ago.
i hate frameworks but tailwind is one of the ugliest ones i know. and i'm a person who uses utility classes a lot. they have a place and a purpose but when everything is a utility class what should have been easy becomes difficult. even the ready made components from headlessui are difficult to setup and adapt for any purpose that's slightly outside of what the component was designed for. yes, you can configure and extend every minute detail of tailwind but i think most people just want a tool that works, not something that needs hours to setups and then go back and tweak. and this is on a good day, when the designer works with you, not against you. and then there's plugins and libraries that extend tailwind itself which brings another config file and another documentation page on top of all the others. no wonder project take longer than ever to finish.