3 ms·

There is a dead sibling comment which I will repeat with a bit kinder words, and with a different caveat. As a frontend developer I don’t like Tailwind for sev

There is a dead sibling comment which I will repeat with a bit kinder words, and with a different caveat. As a frontend developer I don’t like Tailwind for several reasons, it brings the styling into the structure. As a frontend developer Tailwind is at a forefront of what I would consider bad practice and encourages a code style which would be a nightmare for me to maintain. That said. Tailwind seems to be loved be people who are not professional frontend developers. It seems to be just the right tool for people who are not necessarily proficient in CSS. And perhaps people like me (and the dead sibling) need to learn to let go and allow other people to have the tools which makes it easier for them to do the job which they are not experts at. For that reason I understand Tailwind, even though I don’t agree with it.

deleted 5y ago
[deleted]
lghh 5y ago
I think TWCSS' argument is that we always were bringing the styling into the structure. Show me a site that has CSS Zen garden style replaceable stylesheets that totally overhaul the nature of the site. It's incredibly rare and almost always not worth the effort. What business says "I want to overhaul the styles of my application but change no structure at all. I'd posit it's near 0. Even if that's your goal, and I'd argue that it shouldn't be, you can still do that with TWCSS and the @apply keyword. You can write your generalized names then apply whatever twcss keywords you want to them separate from your document's structure. If your overhaul amounts to changing a "theme" you can easily do that with twcss. In fact, that's basically the point. I am a professional frontend developer and I love it.
rekoros 5y ago
I like Tailwind because it brings styling into structure. Dealing with external CSS has always been really challenging for me, and I've always heretically used inline CSS. I mean header files are OK, and professional C developers probably love them, but not having header files is kind of great too :)
skipants 5y ago
I think your comment has a lot of merit. Personally Tailwind has been awesome but I think it's because it makes all these abstractions for you. It also forces less experienced developers to follow this abstraction rather than making their own, which usually ends up as a ball of spaghetti. I have a similar comment elsewhere in the thread but it applies here too, I think: the main drawback of Tailwind is that it's extremely general. I'd imagine a well abstracted, focused, domain-specific set of CSS created by experienced frontend developers will be much better within that domain.
toomanydoubts 5y ago
I have said it many times, but I'll have a go at it again. The reason why inline styles got it's bad reputation is mainly because we used to have no way of building reusable components. Nowadays, everyone and their mothers are using some kind of frontend framework that allows you to reuse components, so your inline styles can be mentioned once and used everywhere. It's not a problem anymore. Pair your tailwind with styled components and you can finally reach the dream of semantic HTML.
valtism 5y ago
I am a professional frontend developer working on a large-scale react application and I love tailwind. I am proficient in CSS, but having colocated html (well, JSX) and css makes so much sense, and the design system really helps fast iteration while also keeping things looking nice.
progx 5y ago
As a frontend developer you should hear about components. Or did you develop websites not apps?
- runarberg 5y ago
  I do components all the time, and I usually do component scoped styles.
iovrthoughtthis 5y ago
do you prefer the structure in the styling or the styling in the structure? i prefer the later. with styling in structure if i make a change in one place, it effects the one thing i intended it to with structure in styling, if i change one thing, it may impact many other things, some of which i might not intend to and are sometimes unknowable at the time of the change
- runarberg 5y ago
  I usually do component scoped styles (e.g. shadow DOM, Vue’s SFC, React’s styled components, etc.) and the changes I do only affect the component where the changes occurred. So to answer your question, I like structure in styling, but with component scoped styles that structure can be pretty minimal. If I change the structure I usually have to change the style anyway. And with component scoped styles, I know exactly where I need to do that (usually in the same file, or in a file referenced by the component). As for shared styles I use the cascade which can penetrate the component boundaries, e.g. font-size, color, but usually --css-custom-properties.

deleted 5y ago

[deleted]

lghh 5y ago

I think TWCSS' argument is that we always were bringing the styling into the structure. Show me a site that has CSS Zen garden style replaceable stylesheets that totally overhaul the nature of the site. It's incredibly rare and almost always not worth the effort. What business says "I want to overhaul the styles of my application but change no structure at all. I'd posit it's near 0. Even if that's your goal, and I'd argue that it shouldn't be, you can still do that with TWCSS and the @apply keyword. You can write your generalized names then apply whatever twcss keywords you want to them separate from your document's structure. If your overhaul amounts to changing a "theme" you can easily do that with twcss. In fact, that's basically the point. I am a professional frontend developer and I love it.

rekoros 5y ago

I like Tailwind because it brings styling into structure. Dealing with external CSS has always been really challenging for me, and I've always heretically used inline CSS. I mean header files are OK, and professional C developers probably love them, but not having header files is kind of great too :)

skipants 5y ago

I think your comment has a lot of merit. Personally Tailwind has been awesome but I think it's because it makes all these abstractions for you. It also forces less experienced developers to follow this abstraction rather than making their own, which usually ends up as a ball of spaghetti. I have a similar comment elsewhere in the thread but it applies here too, I think: the main drawback of Tailwind is that it's extremely general. I'd imagine a well abstracted, focused, domain-specific set of CSS created by experienced frontend developers will be much better within that domain.

toomanydoubts 5y ago

I have said it many times, but I'll have a go at it again. The reason why inline styles got it's bad reputation is mainly because we used to have no way of building reusable components. Nowadays, everyone and their mothers are using some kind of frontend framework that allows you to reuse components, so your inline styles can be mentioned once and used everywhere. It's not a problem anymore. Pair your tailwind with styled components and you can finally reach the dream of semantic HTML.

valtism 5y ago

I am a professional frontend developer working on a large-scale react application and I love tailwind. I am proficient in CSS, but having colocated html (well, JSX) and css makes so much sense, and the design system really helps fast iteration while also keeping things looking nice.

progx 5y ago

As a frontend developer you should hear about components. Or did you develop websites not apps?

runarberg 5y ago
I do components all the time, and I usually do component scoped styles.

iovrthoughtthis 5y ago

do you prefer the structure in the styling or the styling in the structure? i prefer the later. with styling in structure if i make a change in one place, it effects the one thing i intended it to with structure in styling, if i change one thing, it may impact many other things, some of which i might not intend to and are sometimes unknowable at the time of the change

runarberg 5y ago
I usually do component scoped styles (e.g. shadow DOM, Vue’s SFC, React’s styled components, etc.) and the changes I do only affect the component where the changes occurred. So to answer your question, I like structure in styling, but with component scoped styles that structure can be pretty minimal. If I change the structure I usually have to change the style anyway. And with component scoped styles, I know exactly where I need to do that (usually in the same file, or in a file referenced by the component). As for shared styles I use the cascade which can penetrate the component boundaries, e.g. font-size, color, but usually --css-custom-properties.