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 ( TehPers@beehaw.org ) English
    6·
    5 days 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.

    • TehPers ( TehPers@beehaw.org ) English
      3·
      5 days 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.