4 ms·

I think you’re spot on - development is a big tent and it’s totally cool for this to be personal preference.

ricardobeat 6y ago
I think there's more than personal preference at play here. The hidden benefit that the author missed is that Tailwind's (or any other atomic CSS approach) classes are immutable and all changes localized. This pays off hugely for large [enterprise] projects. In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else. With class-based styles, even when using theme variables, there is always the chance you end up breaking something at a distance by adding a property to an existing class, changing a shared value, renaming a selector or changing it's precedence. If you find yourself in this environment where dozens of people are making changes concurrently, and these issues are a daily occurrence, naturally you'll wonder how you ever worked with CSS any other way. styled-jsx and other approaches can get you similar benefits but extra care is necessary. I mostly avoid Tailwind due to the lock-in, complex setup and slow build, otherwise might have used it for quick prototypes more often.
- monkey_monkey 6y ago
  The slow build is definitely an issue, although that's generally only a factor when you're customising Tailwind, not when you're just using the classes in your HTML. (I'm sure you know this, just adding it for clarification). However, the Tailwind team are very close to releasing something that is, apparently, going to dramatically speed up build times (source: Adam Wathan's recent tweets).
  - ricardobeat 6y ago
    The complete Tailwind bundle is 3MB in size - optimizing for production (pruning unused classes) is necessary even if you're not using customization.
    - monkey_monkey 6y ago
      Sure, but that's just part of the deployment process and adds a few seconds to it, it's not something that hampers you (generally) with development.
- nicoburns 6y ago
  > In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else Isn't the flip side of this that it makes it almost impossible to keep styles (visually) consistent across the codebase?
  - christophilus 6y ago
    The opposite. Tailwind pretty much guarantees you’ve got consistent ratios, colors, etc across your product.
    - Macha 6y ago
      Our experience has been absolutely not with an inhouse atomic css framework we ultimately ripped out of a project. Something like pd-md (for "medium padding") gets applied somewhere, then the decision is made that e.g. buttons should have less padding unless they're in a dialog, so someone goes around replacing it with "pd-sm" on buttons except they miss some and other developers don't get the message and add new buttons still using "pd-md" as they just copied and pasted the styling from a button that hadn't been updated and all of a sudden different forms have different padding on all your buttons, something that wouldn't have happened if making a button was just applying class="button".
      - 9dev 6y ago
        For me it makes sense to create a component class in that case, using Tailwind‘s `@apply` to add the generic padding: .button { @apply py-2 px-4; } This ensures CI elements are styled the same way everywhere, but still relies on the Tailwind config to figure out what „2 abstract units of vertical padding“ mean in your application.
        Macha 6y ago
        But then why not go all the way and do .button { padding: var(--medium-padding) var(--medium-padding); } Or use LESS/SCSS/etc if the var(--) syntax is really that offputting.
- smaudet 6y ago
  "In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else." I sometimes wonder if people even understand what technology they are using: CSS = Cascading Style Sheets Go read some history, as to why exactly they were created. What you are describing is not CSS at all, that's properties on a design grid. Which goes back to the author's point - if you want or really need that, don't use CSS. Just use components with standalone properties. Use CSS when you want to be 100% sure it will change everything else.
- Scooty 6y ago
  I'm pretty skeptical about lock in. If I couldn't use tailwind tomorrow, I think I could rewrite the few dozen minimal utility classes I need in a matter of hours. IMO the implementation is a convenience.

I think there's more than personal preference at play here. The hidden benefit that the author missed is that Tailwind's (or any other atomic CSS approach) classes are immutable and all changes localized. This pays off hugely for large [enterprise] projects. In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else. With class-based styles, even when using theme variables, there is always the chance you end up breaking something at a distance by adding a property to an existing class, changing a shared value, renaming a selector or changing it's precedence. If you find yourself in this environment where dozens of people are making changes concurrently, and these issues are a daily occurrence, naturally you'll wonder how you ever worked with CSS any other way. styled-jsx and other approaches can get you similar benefits but extra care is necessary. I mostly avoid Tailwind due to the lock-in, complex setup and slow build, otherwise might have used it for quick prototypes more often.

monkey_monkey 6y ago
The slow build is definitely an issue, although that's generally only a factor when you're customising Tailwind, not when you're just using the classes in your HTML. (I'm sure you know this, just adding it for clarification). However, the Tailwind team are very close to releasing something that is, apparently, going to dramatically speed up build times (source: Adam Wathan's recent tweets).
- ricardobeat 6y ago
  The complete Tailwind bundle is 3MB in size - optimizing for production (pruning unused classes) is necessary even if you're not using customization.
  - monkey_monkey 6y ago
    Sure, but that's just part of the deployment process and adds a few seconds to it, it's not something that hampers you (generally) with development.
nicoburns 6y ago
> In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else Isn't the flip side of this that it makes it almost impossible to keep styles (visually) consistent across the codebase?
- christophilus 6y ago
  The opposite. Tailwind pretty much guarantees you’ve got consistent ratios, colors, etc across your product.
  - Macha 6y ago
    Our experience has been absolutely not with an inhouse atomic css framework we ultimately ripped out of a project. Something like pd-md (for "medium padding") gets applied somewhere, then the decision is made that e.g. buttons should have less padding unless they're in a dialog, so someone goes around replacing it with "pd-sm" on buttons except they miss some and other developers don't get the message and add new buttons still using "pd-md" as they just copied and pasted the styling from a button that hadn't been updated and all of a sudden different forms have different padding on all your buttons, something that wouldn't have happened if making a button was just applying class="button".
    - 9dev 6y ago
      For me it makes sense to create a component class in that case, using Tailwind‘s `@apply` to add the generic padding: .button { @apply py-2 px-4; } This ensures CI elements are styled the same way everywhere, but still relies on the Tailwind config to figure out what „2 abstract units of vertical padding“ mean in your application.
      - Macha 6y ago
        But then why not go all the way and do .button { padding: var(--medium-padding) var(--medium-padding); } Or use LESS/SCSS/etc if the var(--) syntax is really that offputting.
smaudet 6y ago
"In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else." I sometimes wonder if people even understand what technology they are using: CSS = Cascading Style Sheets Go read some history, as to why exactly they were created. What you are describing is not CSS at all, that's properties on a design grid. Which goes back to the author's point - if you want or really need that, don't use CSS. Just use components with standalone properties. Use CSS when you want to be 100% sure it will change everything else.
Scooty 6y ago
I'm pretty skeptical about lock in. If I couldn't use tailwind tomorrow, I think I could rewrite the few dozen minimal utility classes I need in a matter of hours. IMO the implementation is a convenience.