Most UI kits let you pass any style as a prop — radius, size, color, or a wall of Tailwind classes, whatever you need. That flexibility is exactly the problem: it turns every component call into a one-off styling decision, and no two buttons end up the same. Let's talk about practices that prevent building an inconsistent, unmaintainable code base that won't scale.
  • TehPers@beehaw.orgEnglish
    7·
    1 day ago

    Tailwind class soup is something I see often in LLM-generated code. For some reason, every starter template in existence decided to include Tailwind, and then the coworker generating this code (who doesn’t have frontend experience at all) just rolls with whatever the LLM shits out.

    I believe there’s a proper way to use Tailwind, but I can’t be bothered to read the docs for it. It makes far more sense to me to either use plain CSS or, if I’m using a component library, then whatever that library comes with for its theming system.

    Also, this whole article basically boils down to “use a proper theming system”, which it even admits can be as simple as some CSS classes with standardized names.

    • some_designer_dude@lemmy.worldEnglish
      11·
      1 day ago

      Eh, if you’re using React or any other modern app framework (or “library” as they call themselves) then Tailwind classes are nicer for co-locating styles with their respective components. Vue lets you co-locate the actual style block, but even that’s not as nice as seeing the styles directly on the elements themselves. There are still uses for global-level CSS of course, but there’s no “central” place for those besides the html tag.

    • TehPers@beehaw.orgEnglish
      2·
      1 day ago

      For what it’s worth, modern component libraries compile the styles to CSS classes anyway. I don’t know why they choose to go through the convoluted process they do to generate those classes, but the user usually just sees classes at least.