4 ms·

The problem with tailwind is it does away with separation of concerns and messes up HTML, like the old styling tags in HTML. We moved on from those for good rea

The problem with tailwind is it does away with separation of concerns and messes up HTML, like the old styling tags in HTML. We moved on from those for good reasons.

christophilus 2y ago
It really isn’t the same as inline styles at all. It’s the best of both worlds, in my opinion. It’s hard to see myself ever going back to the old ways.
- nawgz 2y ago
  It's the exact same as inline styles...
  - foco_tubi 2y ago
    it's really not - utility classes avoid specificity conflicts and enforces a consistent design system as defined in the Tailwind config.
- bromuro 2y ago
  I have given a chance to Tailwind and it was neither nice or easy. I actually give up, wondering why my younger colleagues appreciate writing CSS using class names. I write CSS since its debut. Clearly it wasn’t enough suffering: they reimplemented it as a class-name based language - with horrible IDE support. I am perplexed - I must be the boomer around here… :)
  - andrei_says_ 2y ago
    I think it makes sense when writing css for isolated components - usually ignoring the cascade. Makes it possible to not name things which is a plus in componentworld. The thing is, it’s the cascade that makes css as powerful and elegant as it is. And not naming the things comes at the cost of listing all css properties as classes on each element. I write CSS and must say that in 2024 CSS is an amazingly powerful and elegant language. If one is willing / given the time to learn it. Using conventions like ITCSS, a few libraries like https://utopia.fyi https://utopia.fyi and placing colors, font sizes and spacing into variables + the use of a few utility classes provide most of the conveniences of a utility-first framework with no downsides. I can also see how devs focusing on components prefer utility-first frameworks for the speed of development. Despite the low maintainability and the horrible markup.
    - alwillis 2y ago
      +1 for ITCSS

The problem with tailwind is it does away with separation of concerns and messes up HTML, like the old styling tags in HTML. We moved on from those for good reasons.

christophilus 2y ago

It really isn’t the same as inline styles at all. It’s the best of both worlds, in my opinion. It’s hard to see myself ever going back to the old ways.

nawgz 2y ago
It's the exact same as inline styles...
- foco_tubi 2y ago
  it's really not - utility classes avoid specificity conflicts and enforces a consistent design system as defined in the Tailwind config.
bromuro 2y ago
I have given a chance to Tailwind and it was neither nice or easy. I actually give up, wondering why my younger colleagues appreciate writing CSS using class names. I write CSS since its debut. Clearly it wasn’t enough suffering: they reimplemented it as a class-name based language - with horrible IDE support. I am perplexed - I must be the boomer around here… :)
- andrei_says_ 2y ago
  I think it makes sense when writing css for isolated components - usually ignoring the cascade. Makes it possible to not name things which is a plus in componentworld. The thing is, it’s the cascade that makes css as powerful and elegant as it is. And not naming the things comes at the cost of listing all css properties as classes on each element. I write CSS and must say that in 2024 CSS is an amazingly powerful and elegant language. If one is willing / given the time to learn it. Using conventions like ITCSS, a few libraries like https://utopia.fyi https://utopia.fyi and placing colors, font sizes and spacing into variables + the use of a few utility classes provide most of the conveniences of a utility-first framework with no downsides. I can also see how devs focusing on components prefer utility-first frameworks for the speed of development. Despite the low maintainability and the horrible markup.
  - alwillis 2y ago
    +1 for ITCSS