3 ms·

> What would be a few, maybe even half dozen, lines of CSS in a separate file, are now shoved into the generated code, and repeated everywhere. ... > One of t

> What would be a few, maybe even half dozen, lines of CSS in a separate file, are now shoved into the generated code, and repeated everywhere. ... > One of the bits of advice Tailwind gives is to use @apply and extract common blobs of CSS into common classes2. > Why bother to even use @apply? Just write the damn CSS If you take a look at the official Tailwind docs (https://tailwindcss.com/docs/reusing-styles#extracting-components-and-partials https://tailwindcss.com/docs/reusing-styles#extracting-compo...) they say: "If you need to reuse some styles across multiple files, the best strategy is to create a component if you’re using a front-end framework like React, Svelte, or Vue, or a template partial if you’re using a templating language like Blade, ERB, Twig, or Nunjucks. ... While it’s highly recommended that you create proper template partials for more complex components, you can use Tailwind’s @apply directive to extract repeated utility patterns to custom CSS classes when a template partial feels heavy-handed." So Tailwind recommends the use of components/template-partials as the way to reuse styles (e.g. your styled button HTML with classes goes in `button.html` and you reuse that for each button) because they think reusing styles in the traditional CSS way via classes doesn't scale (https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first). I know it's trendy to bash modern webdev here but people criticising Tailwind should at least try and understand the Tailwind approach first. Same with comments like "it's just inline styles" - they cover common knee-jerk reactions like this in the docs (https://tailwindcss.com/docs/utility-first#why-not-just-use-inline-styles https://tailwindcss.com/docs/utility-first#why-not-just-use-...). You know how it's popular now to prefer composition over inheritance in OOP languages because it scales better? Tailwind is more like that, whereas CSS is more about preferring inheritance via cascading rules. Tailwind advocates their approach scales better to complex custom web designs. If you're just styling basic documents, you're not going to see much benefit.

kykeonaut 3y ago
Which is no different from creating a styles.css file, writing your classes there, and importing it into your html...
- seanwilson 3y ago
  Tailwind is more like you create lot of (utility) classes in your styles.css file that tweak just one styling property like a font, a color or a margin, and then reuse those classes to style each of your UI components like buttons and headers. With traditional CSS, you would assign a class to each UI component and then write custom CSS for each one. Usually people try to share CSS between classes but then you have to be really careful you don't break unrelated components as you make changes later. Read the Tailwind links above to understand more about the pros/cons of each approach.
  - kykeonaut 3y ago
    I do think that the real value of Tailwind comes from the utility classes, rather than css-in-html paradigm. You could achieve the same, for example, with Pollen.css [0] or Open Props [1]. [0] https://github.com/heybokeh/pollen https://github.com/heybokeh/pollen [1] https://github.com/argyleink/open-props https://github.com/argyleink/open-props
    - seanwilson 3y ago
      This covers the design token part but it's very verbose (especially when you need responsive behaviour) when you want to iterate on styling a component compared to Tailwind and doesn't cover the other problems with CSS mentioned in https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first. I guess it depends how complex your designs are?
yawnxyz 3y ago
The "just write a component" strategy is really bad if you're trying to reuse your CSS across different projects and frameworks. I just want my buttons and cards and components to LOOK the same, not function the same. I actively go against their "just create a component" strategy and I find it overcomes all the Tailwind limitations.
- seanwilson 3y ago
  > The "just write a component" strategy is really bad if you're trying to reuse your CSS across different projects and frameworks. I just want my buttons and cards and components to LOOK the same, not function the same. Could you explain the problem more? There's lots of Tailwind based component systems that have reusable button and card components you could look at for ideas how to structure this. In comparison, reusing traditional CSS is usually a nightmare because the CSS for a single component is usually spread across multiple files and difficult to disentangle. That's part of the problem Tailwind tries to solve.

kykeonaut 3y ago

Which is no different from creating a styles.css file, writing your classes there, and importing it into your html...

seanwilson 3y ago
Tailwind is more like you create lot of (utility) classes in your styles.css file that tweak just one styling property like a font, a color or a margin, and then reuse those classes to style each of your UI components like buttons and headers. With traditional CSS, you would assign a class to each UI component and then write custom CSS for each one. Usually people try to share CSS between classes but then you have to be really careful you don't break unrelated components as you make changes later. Read the Tailwind links above to understand more about the pros/cons of each approach.
- kykeonaut 3y ago
  I do think that the real value of Tailwind comes from the utility classes, rather than css-in-html paradigm. You could achieve the same, for example, with Pollen.css [0] or Open Props [1]. [0] https://github.com/heybokeh/pollen https://github.com/heybokeh/pollen [1] https://github.com/argyleink/open-props https://github.com/argyleink/open-props
  - seanwilson 3y ago
    This covers the design token part but it's very verbose (especially when you need responsive behaviour) when you want to iterate on styling a component compared to Tailwind and doesn't cover the other problems with CSS mentioned in https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first. I guess it depends how complex your designs are?

yawnxyz 3y ago

The "just write a component" strategy is really bad if you're trying to reuse your CSS across different projects and frameworks. I just want my buttons and cards and components to LOOK the same, not function the same. I actively go against their "just create a component" strategy and I find it overcomes all the Tailwind limitations.

seanwilson 3y ago
> The "just write a component" strategy is really bad if you're trying to reuse your CSS across different projects and frameworks. I just want my buttons and cards and components to LOOK the same, not function the same. Could you explain the problem more? There's lots of Tailwind based component systems that have reusable button and card components you could look at for ideas how to structure this. In comparison, reusing traditional CSS is usually a nightmare because the CSS for a single component is usually spread across multiple files and difficult to disentangle. That's part of the problem Tailwind tries to solve.