4 ms·

I really like utility classes and think Tailwind is really smart for many usecases, but the drawback with Tailwind is even if you componentize, your code is spr

by gedy 4y ago

I really like utility classes and think Tailwind is really smart for many usecases, but the drawback with Tailwind is even if you componentize, your code is sprinkled with very specific visual classes like for shadows, border radius, etc. When companies want to refresh their look and feel, it's really annoying to change everything to remove now unwanted shadows, etc. In spite of it's age, I've found Bootstrap is better for this as it uses predefined component classes that can be restyled without rewriting the app or components (but also has some handy utility classes). I know you can define your own component classes in TW, but then you've just recreated Bootstrap/Bulma/etc, but with no 3rd party components available. (Tailwind UI is just some limited copy paste code snippets last I looked.)

bpicolo 4y ago
> but with no 3rd party components available There are a bunch of great 3rd party components available in tailwind now. https://daisyui.com/ https://daisyui.com/ is one I've been using. They're usually a tad bit lower level than typical framework component libs, but the flexibility is great. A great thing about that is they're not React-specific, Vue-specific, etc. You can use them in everything from raw html to your JS library flavor of choice.
- gedy 4y ago
  DaisyUI is a nice approach and hope it succeeds. We were looking to use that until we realized it's almost identical to Bootstrap, and that we were just using Tailwind as an elaborate way to make a custom Bootstrap theme at build time. Company decided to go with BS5 instead.
likortera 4y ago
Have you ever had to change the company's look and feel with anything else than tailwind? I had to do it with a BEM codebase, and I also had to do it with tailwind. The tailwind situation was by far the easiest one. And it was because I was not afraid to remove things that could break unrelated parts of the application. Not allowing developer to hand write CSS is a great restriction for a good bunch of developers. The messes out there are unbelievable.
- gedy 4y ago
  > Not allowing developer to hand write CSS is a great restriction for a good bunch of developers. I agree, main point is that I think there are better tools for large codebases. We had a "no CSS" rule where we used bootstrap components and utility classes only.
- calvinmorrison 4y ago
  > Have you ever had to change the company's look and feel with anything else than tailwind? Yes, many times, with normal CSS. It's basically the point of cascading style sheets. Sticking to proper class names and elements makes reskinning a breeze.
  - likortera 4y ago
    > It's basically the point of cascading style sheets The "cascading" part is what makes it incredibly complicated. Keeping the "cascade" in sync with the actual markup is not a trivial task in teams with many people of different skills levels. Not everyone is a top 1% dev, so we need easier and safer tools so that everyone can work and maintain a codebase. > Sticking to proper class names and elements makes reskinning a breeze. This is more easily said than done. It's like saying "Just don't write bugs". Every single project I find that has been built with BEM and similar patches after a couple years are just a mess and their CSS becomes "append only", as there's no guarantee that removing something won't break in unexpected ways.
    - calvinmorrison 4y ago
      You're just shifting work though. The commit will now contain 10000 non html structure changes to an html, phtml, whatever, instead styles to a CSS sheet. Might as well go back to doing inline styles. There's a reason we don't do that anymore.
      - deleted 4y ago
        [deleted]
      - 4y ago

by gedy 4y ago

bpicolo 4y ago

> but with no 3rd party components available There are a bunch of great 3rd party components available in tailwind now. https://daisyui.com/ https://daisyui.com/ is one I've been using. They're usually a tad bit lower level than typical framework component libs, but the flexibility is great. A great thing about that is they're not React-specific, Vue-specific, etc. You can use them in everything from raw html to your JS library flavor of choice.

gedy 4y ago
DaisyUI is a nice approach and hope it succeeds. We were looking to use that until we realized it's almost identical to Bootstrap, and that we were just using Tailwind as an elaborate way to make a custom Bootstrap theme at build time. Company decided to go with BS5 instead.

likortera 4y ago

Have you ever had to change the company's look and feel with anything else than tailwind? I had to do it with a BEM codebase, and I also had to do it with tailwind. The tailwind situation was by far the easiest one. And it was because I was not afraid to remove things that could break unrelated parts of the application. Not allowing developer to hand write CSS is a great restriction for a good bunch of developers. The messes out there are unbelievable.

gedy 4y ago
> Not allowing developer to hand write CSS is a great restriction for a good bunch of developers. I agree, main point is that I think there are better tools for large codebases. We had a "no CSS" rule where we used bootstrap components and utility classes only.
calvinmorrison 4y ago
> Have you ever had to change the company's look and feel with anything else than tailwind? Yes, many times, with normal CSS. It's basically the point of cascading style sheets. Sticking to proper class names and elements makes reskinning a breeze.
- likortera 4y ago
  > It's basically the point of cascading style sheets The "cascading" part is what makes it incredibly complicated. Keeping the "cascade" in sync with the actual markup is not a trivial task in teams with many people of different skills levels. Not everyone is a top 1% dev, so we need easier and safer tools so that everyone can work and maintain a codebase. > Sticking to proper class names and elements makes reskinning a breeze. This is more easily said than done. It's like saying "Just don't write bugs". Every single project I find that has been built with BEM and similar patches after a couple years are just a mess and their CSS becomes "append only", as there's no guarantee that removing something won't break in unexpected ways.
  - calvinmorrison 4y ago
    You're just shifting work though. The commit will now contain 10000 non html structure changes to an html, phtml, whatever, instead styles to a CSS sheet. Might as well go back to doing inline styles. There's a reason we don't do that anymore.
    - deleted 4y ago
      [deleted]
    - 4y ago