4 ms·

I believe the solution here is most definitely @apply. I know the Tailwind team seem to be against @apply (and even flirted with removing it), but having used i

I believe the solution here is most definitely @apply. I know the Tailwind team seem to be against @apply (and even flirted with removing it), but having used it extensively to build complex (imo) sites and apps, @apply has been unavoidable and actually great to have. The fact is @apply is there and if we're using it and there's enough push-back, I don't see why the Tailwind team wouldn't listen to that or create a workable upgrade path for those who wish to continue to use it. So use the tools you have - don't avoid it just because the core team dislike it. They can't remove it in the version you have installed today (unless they have some magical way to reach into your computer/server)

blowski 4y ago
In general, framework owners _want_ you to become tightly coupled to the framework, whereas as a user you want to be able to move away from it more easily. I think this conflict of interests is behind recommendations like this, rather than sound technical reasons.
- abujazar 4y ago
  Why would framework owners want you to become tightly coupled to the framework? They're basically just offering a set of solutions that come with some tradeoffs, but they don't intentionally create problems for their users.
  - blowski 4y ago
    For framework owners that have a business built on top of their framework, that tight coupling is their "moat" that helps keep you locked in as a paying customer for longer.
satvikpendem 4y ago
Sure, I've already moved onto CSS in TS solutions like vanilla-extract above though, I like my typechecking in my CSS.
di4na 4y ago
The real answer is in CSS developing a proper supported way to do mixins. I keep being surprised that noone bring this up in these discussions.
- presentation 4y ago
  I do it with emotion (CSS in JS), specifically NOT using styled components and instead using the CSS prop which allows for composing styles more naturally, and it works great. Never felt a need to get my team on Tailwind since it’s already super productive with the right set of mixins.
  - di4na 4y ago
    I get you, the problem is that CSS in JS is simply not possible for the vast majority of web developers out there that work on a site render framework that is not JS ;) I think this is the main reason why Tailwind took off so fast. The frontend tooling world forgot the majority of its users.
tekkk 4y ago
Yeah I don't understand what the other solution would be. If you want to have reusable styles, eg "btn" class with all your defaults @apply is the obvious choice. Otherwise you'll end up with similar gargantuan CSS class spagetti and/or have to abstract away some generic components because handling the classes is just too much.
- mvf4z7 4y ago
  I was under the impression that you create a button component and apply the atomic styles in that component. That way you don’t don’t need a “btn” class, you just use the Button component anywhere you need a button.
  - lawn 4y ago
    This assumes you only have one button class, while you might want to reuse several that have minor differences.
  - tekkk 4y ago
    You could do that but many of the minor stylings might not warrant a component, like a specific hover effect. For quick prototyping though it just is way more convenient to not to constantly break apart small html snippets into their own components.
  - eckmLJE 4y ago
    What if you need to render your button component as an anchor element? Or as a div with role="button"? You will want to abstract your button styles somehow so that they can be shared between these three (or more) use cases. Sure you could experiment with using a polymorphic `as` prop to render your button component as any element, but if you're using TypeScript that can get complicated quickly, especially if you're then trying to use that component in conjunction with something like next/link or react-router/link. It's simpler to strip default styles from all your components, and then have a button class to add to any element you want to appear as a button. BUT, then what if you want to add some kind of special behavior to your button that involves subcomponents, e.g. a loading state that conditionally renders a spinner inside the button? Or you want to provide convenience props like rendering an icon before or after the button text? Then a class is not enough. If you're building a design system/component library, none of these options are simple and there are always tradeoffs.

blowski 4y ago

In general, framework owners _want_ you to become tightly coupled to the framework, whereas as a user you want to be able to move away from it more easily. I think this conflict of interests is behind recommendations like this, rather than sound technical reasons.

abujazar 4y ago
Why would framework owners want you to become tightly coupled to the framework? They're basically just offering a set of solutions that come with some tradeoffs, but they don't intentionally create problems for their users.
- blowski 4y ago
  For framework owners that have a business built on top of their framework, that tight coupling is their "moat" that helps keep you locked in as a paying customer for longer.

satvikpendem 4y ago

Sure, I've already moved onto CSS in TS solutions like vanilla-extract above though, I like my typechecking in my CSS.

di4na 4y ago

The real answer is in CSS developing a proper supported way to do mixins. I keep being surprised that noone bring this up in these discussions.

presentation 4y ago
I do it with emotion (CSS in JS), specifically NOT using styled components and instead using the CSS prop which allows for composing styles more naturally, and it works great. Never felt a need to get my team on Tailwind since it’s already super productive with the right set of mixins.
- di4na 4y ago
  I get you, the problem is that CSS in JS is simply not possible for the vast majority of web developers out there that work on a site render framework that is not JS ;) I think this is the main reason why Tailwind took off so fast. The frontend tooling world forgot the majority of its users.

tekkk 4y ago

Yeah I don't understand what the other solution would be. If you want to have reusable styles, eg "btn" class with all your defaults @apply is the obvious choice. Otherwise you'll end up with similar gargantuan CSS class spagetti and/or have to abstract away some generic components because handling the classes is just too much.

mvf4z7 4y ago
I was under the impression that you create a button component and apply the atomic styles in that component. That way you don’t don’t need a “btn” class, you just use the Button component anywhere you need a button.
- lawn 4y ago
  This assumes you only have one button class, while you might want to reuse several that have minor differences.
- tekkk 4y ago
  You could do that but many of the minor stylings might not warrant a component, like a specific hover effect. For quick prototyping though it just is way more convenient to not to constantly break apart small html snippets into their own components.
- eckmLJE 4y ago
  What if you need to render your button component as an anchor element? Or as a div with role="button"? You will want to abstract your button styles somehow so that they can be shared between these three (or more) use cases. Sure you could experiment with using a polymorphic `as` prop to render your button component as any element, but if you're using TypeScript that can get complicated quickly, especially if you're then trying to use that component in conjunction with something like next/link or react-router/link. It's simpler to strip default styles from all your components, and then have a button class to add to any element you want to appear as a button. BUT, then what if you want to add some kind of special behavior to your button that involves subcomponents, e.g. a loading state that conditionally renders a spinner inside the button? Or you want to provide convenience props like rendering an icon before or after the button text? Then a class is not enough. If you're building a design system/component library, none of these options are simple and there are always tradeoffs.