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

I use Tailwind utility classes extensively to create reusable components in a Rails app using GitHub's ViewComponent gem (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.

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.

I had the same concern at first. I remained skeptical during my first couple days working with Tailwind, but came around pretty soon thereafter.

I realized that all of my semantic CSS classes might as well have been inline CSS for all the good they were doing me on reusability. Utility classes are faster to work with, and, as long as you’re componentizing everything, still going to give you consistent styles across your product.

The usage of utility classes only become an issue if you have unnecessary duplication of components. Say, two buttons that should be the same but are implemented in different places.

IMO one of the interesting parts of functional CSS is that we can apply the same tactics we use for organising code to organising the styling.

Also, with separated CSS, and especially with semantic CSS, there is often a fair amount of duplication that happens in the CSS code itself, which we programmers tend to be very forgiving of. Giving Tailwind more scrutiny than we do for our CSS ends up making our code more consistent, less duplicated and better in general.

My experience with Tailwind + ViewComponent has been great as well. I've also had a lot of success with adding Sorbet typing to the view components. I often use Sorbet enums as view component options. The extra type safety in the view layer is very helpful.

I hadn’t thought about this. That’s a really good idea. Thanks for sharing!

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.

Those benefits seem the same as the benefits of styled components or css modules?

Looks like Tailwind has an answer to this: @apply. 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.

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

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).

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.

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.

Why would you need a button class when you can have that button in a component?

> 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/