Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don't recommend Tailwind CSS

en.andros.dev

Post reply on HN
Print view View original

111–120 of 179 posts

Re: I don't recommend Tailwind CSS

#111

Post by interstice »

SebastianKra wrote: post #102

We need to talk about two use-cases separately: CSS for design systems is fine. You can define a .button[data-variant=”primary”]. It’s intuitive, performant, makes sense. CSS for application code is terrible — specifically layout & typography. The different kinds of flex/grid layouts are tightly coupled to the dom structure. Tailwind is a great fit here: Title Subtitle When you remove layouting concerns and maybe typ…

For a very long time now I've avoided anything other than 1 class per div with style overrides and written with modular rules and 1-2 degrees of separation between label and rules.

Something like

.title {

  @include type-heading;

  &.LARGE {
    @include font-size-large;
  }

  @include onMobile {
    ...something
  }
}

This has the advantage of being naturally rule based and amazingly succinct to write and understand. Needless to say I'm an odd duck, since I almost never see css written this way.

(edit: I forgot how to format code on HN)

Re: I don't recommend Tailwind CSS

#112

Post by dzonga »

9dev wrote: post #10

This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…

author of the article is making a logical argument - in matters of human behavior. that never works.

author should've instead asked himself & the world - why people are drawn to tailwind. yeah technically it's inferior - but in terms of being optimized for how people do things - tailwind is superior.

Re: I don't recommend Tailwind CSS

#113

Post by shortformblog »

Honestly, I found managing a Bulma codebase significantly more of a pain in the ass than Tailwind. Tailwind offers the expressiveness of actual CSS with the ability to make quick changes on the fly. As someone who has spent a lot of time working in CSS frameworks over the years, it is one of the better abstractions of its kind.

I sort of feel like this argument is trying to put a train that is already halfway across the country back in the station on the East Coast.

Re: I don't recommend Tailwind CSS

#114

Post by atif089 »

9dev wrote: post #88
boxed wrote: post #82

Earlier quoted context omitted.

Projects with a single gigantic CSS file also work and you can onboard people etc. That's not an argument.

they do work… for any value of work . I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another prepro…

> I have been in the industry for a while

> Out of curiosity how long have you been doing frontend development?

I've been writing CSS since IE 6 and I can tell you not a lot of us oldies like tailwind. I've only seen a strong inclination towards Tailwind from the newer generation frontends (2015 and beyond)

Us oldies actually prefer BEM over anything else.

My talking point is based off internal comms from a large'ish company (200+ FE devs) so YMMV

Re: I don't recommend Tailwind CSS

#116

Post by drdaeman »

francislavoie wrote: post #83
zelphirkalt wrote: post #58

Earlier quoted context omitted.

I wouldn't even write such a class name. It smells like bad styling and layouting already. A CSS class should convey some semantic meaning. I would name it after the thing that should be red or green, not "red"/"green". That doesn't tell me anything. Maybe its name could be something like "danger" or "active" or something. Also the 500 looks very sus. Responsive design is best when it avoids such hardcoded numbers an…

Absolutely not. Semantic classes are the wrong way to go. Your components (and their props API) are what encode the semantics. With Tailwind you never need to try to come up with a name for anything relating to style, you just use utility classes. It reduces cognitive load significantly.

And so we’re essentially back to ?

Re: I don't recommend Tailwind CSS

#118

Post by lexicality »

nextaccountic wrote: post #72
francislavoie wrote: post #20

Saying "unless you use @apply" invalidates this article for me. Everyone knows that @apply only exists as an escape hatch, it is not supposed to be used, except for when it's necessary like for compatibility with libraries that declare their own classes that you need to override. The most commonly repeated point in the article is "escape hatches bad" and I think that's completely absurd. Of course you want escape hat…

It makes no sense for me that @apply is frowned upon. It's what makes Tailwind actually kinda usable for me. Without it, markup looks like line noise full of boilerplate that's hard to modify in a systematic way. I think what Tailwind actually needs is more abstractions, not to discourage the use of the sole abstraction @apply

I genuinely don't understand, why would you use `@apply text-center` instead of `text-align: center`?

Like if you're already at the point of setting up stylesheets & classes with a pre-processor why would you do that and not say use scss with some mixins for the more complex reused parts? At that point any IDE plugin that knows CSS can give you completion and your compiled sources will look a lot like the written ones in the dev tools.

Re: I don't recommend Tailwind CSS

#119

Post by andrewingram »

marcus_cemes wrote: post #23
9dev wrote: post #10

This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…

I can see this argument both ways. On the one hand, logically you'd expect the last assignment to take precedence, like the style attribute. On the other, conflicting styles don't make sense. The random outcome, entirely dependent on the Tailwind generation internals, is the worst of all worlds though, it's just an unfortunate side-effect of relying on cascading sheets to drive atomic styles.

> conflicting styles don't make sense

Sometimes true, but one issue here is that because Tailwind utility classes vary from being a 1:1 mapping to a single underlying style rule, to mapping to several, it's not always obvious which classes will conflict.

Re: I don't recommend Tailwind CSS

#120

Post by josefrichter »

Tailwind requires a certain mental shift. That typically comes on a project where you feel like "there needs to be a better way", then you read https://tailwindcss.com/docs/styling-with-utility-classes and feel like BINGO!

Using @apply totally KILLS Tailwind - that's the clearest tell that the author didn't have that moment yet. Hence the other arguments in the article that feel somewhat petty.

Post reply on HN