Hacker News Reader

Comment by 14u2c | Hacker News Reader

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

View on HN

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?

Reply on news.ycombinator.com