4 ms·

> I used the JIT version recently on a new landing page Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all

by lhorie 5y ago

> I used the JIT version recently on a new landing page Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability. Where it gets less fun is when you want widget consistency across multiple areas of a site and across design tweaks over time, since now you have to deal with several `class="..."` strings across multiple files, possibly with class names in arbitrary order, possibly mixed with logic from other templating languages (be it from Django or JSX or whatever). So you can't just grep to achieve the objective of changing styles in one place to affect all instances of some semantic group. Personally I think comparing Tailwind directly against traditional CSS as a whole is painting in too broad strokes. There's a lot of CSS methodologies and also a lot of bad practices (e.g. using SASS indentation as namespacing mechanism and then running into the old problem of specificity), and comparatively, there's a lot more than Tailwind in the atomic CSS space, and more broadly, in the compiled CSS space. Utilities like Bootstrap (e.g. `class="btn btn-primary"`) for example share many benefits of both atomic CSS and "good" subsets of traditional CSS practices (namely, you get memorable short class names, which are also organizable along semantic lines). So there's definitely more shades of gray than just "atomic-css-is-the-best-thing-since-sliced-bread" vs "looks-like-lazy-style-attributes-lol".

dqv 5y ago
Looks like Tailwind has an answer to this: @apply. https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles I am going to give it a try. The argument against using it is that it defeats the purpose of Tailwind, but I think its useful to start by spraying classes until things work and then moving those classes into e.g. btn-primary once the styles become stable and need universality.
- lhorie 5y ago
  Yes, @apply exists, but is generally discouraged (and the rationales are given right on that page) > If you start using @apply for everything, you are basically just writing CSS again and throwing away all of the workflow and maintainability advantages Tailwind gives you Approaching it with moderation is probably worth trying though
  - lewispollard 5y ago
    It's the same as any DRY or optimised code: taking time and effort to make things overly DRY or optimised up front is a waste, building stuff out and then refactoring when you realise it's going to be repeated is a better workflow. With tailwind, that's simple because you take your string of class names, slap an @apply on it, and then use the new classname instead. No, it's not significantly different from just writing CSS then, but it's the workflow that's changed that reduces the friction between prototyping and then refactoring into a reusable design that makes Tailwind nice to work with in my experience (and I'm using it for a large-scale commercial project, not a landing page or static site).
    - hbn 5y ago
      I'm pretty sure the creator's intention is that you basically don't use @apply at all, except maybe edge-cases where Tailwind simply can't be used (for example, I think before v3.0 you couldn't set print styles, i.e. @media print) The intended method of not repeating yourself in Tailwind is using a framework, and writing the styles in the template of the component.
14u2c 5y ago
In the context of component based development, react etc., I believe what you describe is actually very beneficial. Think about a case where instead of doing something <button class="btn btn-primary"> you write an atomic component <MyButton> which uses tailwind internally. With this workflow: * There are no global styles that can have an unknown or unexpected impact on the application when modified. * The component's style is completely encapsulated. It can be placed anywhere in the application without worrying about inherited styles causing problems. edit: formatting
- lhorie 5y ago
  I mentioned downthread about a project called Styletron, which has styled-components-like devexp, but compiles to atomic CSS for the bundle size benefits. Another variation I've seen is a combination of atomic CSS and Mithril.js' hyperscript selector syntax, which lets you do stuff like this: const Button = 'button.bg-gray-900.px-6.text-white'; // JSX return <Button>Click me</Button> There definitely are interesting ways of applying atomic CSS beyond basic Tailwind usage.
- aaronbrethorst 5y ago
  I use Tailwind utility classes extensively to create reusable components in a Rails app using GitHub's ViewComponent gem (https://viewcomponent.org https://viewcomponent.org) Occasionally, I'll use @apply directives to DRY up something that isn't easy to encapsulate at the component level, but 95% of the time, I can easily get by with utility classes. I try to avoid using hyperbolic-sounding language like 'revolutionized,' but Tailwind + ViewComponent has basically revolutionized the way I build user interfaces in Rails.
  - stanislavb 5y ago
    Thanks mate! I've been considering this path and may give it a go. Although, I'm still a bit nervous spitting utility classes all around. That sounds almost like inline CSS and almost unmaintainable.
    - 5y ago
jeppester 5y ago
We recently started using a combination of tailwind and BEM instead of bootstrap. It means that we can have our own custom "button button--sm" classes - a single place to change general styling - and on top of that get all flexibility of the tailwind utils for edge cases. I don't think it's perfect, but it's so far much more flexible than bootstrap, and we don't need to duplicate loads of classes for each similar component.
- meerita 5y ago
  Why would you need a button class when you can have that button in a component?
meerita 5y ago
> Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability. It doesn't matter, you can have an entire newspaper and perfectly done in functional css with incredible results without having to mastermind any architecture. http://minid.net/2019/08/12/in-defense-of-functional-css/ http://minid.net/2019/08/12/in-defense-of-functional-css/

by lhorie 5y ago

dqv 5y ago

Looks like Tailwind has an answer to this: @apply. https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles I am going to give it a try. The argument against using it is that it defeats the purpose of Tailwind, but I think its useful to start by spraying classes until things work and then moving those classes into e.g. btn-primary once the styles become stable and need universality.

lhorie 5y ago
Yes, @apply exists, but is generally discouraged (and the rationales are given right on that page) > If you start using @apply for everything, you are basically just writing CSS again and throwing away all of the workflow and maintainability advantages Tailwind gives you Approaching it with moderation is probably worth trying though
- lewispollard 5y ago
  It's the same as any DRY or optimised code: taking time and effort to make things overly DRY or optimised up front is a waste, building stuff out and then refactoring when you realise it's going to be repeated is a better workflow. With tailwind, that's simple because you take your string of class names, slap an @apply on it, and then use the new classname instead. No, it's not significantly different from just writing CSS then, but it's the workflow that's changed that reduces the friction between prototyping and then refactoring into a reusable design that makes Tailwind nice to work with in my experience (and I'm using it for a large-scale commercial project, not a landing page or static site).
  - hbn 5y ago
    I'm pretty sure the creator's intention is that you basically don't use @apply at all, except maybe edge-cases where Tailwind simply can't be used (for example, I think before v3.0 you couldn't set print styles, i.e. @media print) The intended method of not repeating yourself in Tailwind is using a framework, and writing the styles in the template of the component.

14u2c 5y ago

In the context of component based development, react etc., I believe what you describe is actually very beneficial. Think about a case where instead of doing something <button class="btn btn-primary"> you write an atomic component <MyButton> which uses tailwind internally. With this workflow: * There are no global styles that can have an unknown or unexpected impact on the application when modified. * The component's style is completely encapsulated. It can be placed anywhere in the application without worrying about inherited styles causing problems. edit: formatting

lhorie 5y ago
I mentioned downthread about a project called Styletron, which has styled-components-like devexp, but compiles to atomic CSS for the bundle size benefits. Another variation I've seen is a combination of atomic CSS and Mithril.js' hyperscript selector syntax, which lets you do stuff like this: const Button = 'button.bg-gray-900.px-6.text-white'; // JSX return <Button>Click me</Button> There definitely are interesting ways of applying atomic CSS beyond basic Tailwind usage.
aaronbrethorst 5y ago
I use Tailwind utility classes extensively to create reusable components in a Rails app using GitHub's ViewComponent gem (https://viewcomponent.org https://viewcomponent.org) Occasionally, I'll use @apply directives to DRY up something that isn't easy to encapsulate at the component level, but 95% of the time, I can easily get by with utility classes. I try to avoid using hyperbolic-sounding language like 'revolutionized,' but Tailwind + ViewComponent has basically revolutionized the way I build user interfaces in Rails.
- stanislavb 5y ago
  Thanks mate! I've been considering this path and may give it a go. Although, I'm still a bit nervous spitting utility classes all around. That sounds almost like inline CSS and almost unmaintainable.
  - 5y ago

jeppester 5y ago

We recently started using a combination of tailwind and BEM instead of bootstrap. It means that we can have our own custom "button button--sm" classes - a single place to change general styling - and on top of that get all flexibility of the tailwind utils for edge cases. I don't think it's perfect, but it's so far much more flexible than bootstrap, and we don't need to duplicate loads of classes for each similar component.

meerita 5y ago
Why would you need a button class when you can have that button in a component?

meerita 5y ago

> Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability. It doesn't matter, you can have an entire newspaper and perfectly done in functional css with incredible results without having to mastermind any architecture. http://minid.net/2019/08/12/in-defense-of-functional-css/ http://minid.net/2019/08/12/in-defense-of-functional-css/