Live data from Hacker News

Tailwind is a leaky abstraction

jakelazaroff.com

101–110 of 391 posts

Re: Tailwind is a leaky abstraction

#101
From the many HN discussions over Tailwind, I've kind of anecdotally seen that...

A) Some experienced front end devs have a real issue with it, and B) People who use CSS in passing, like me, tend to really enjoy it.

I want an abstraction over CSS, it makes me life easier. I'm not anywhere advanced in front end as the OP, so maybe that is the difference. But I realize it is what it is - utility classes. I don't get the issue here really - just dip down to CSS if Tailwind isn't doing what you want.

Re: Tailwind is a leaky abstraction

#102
post #3

Tailwind is not an abstraction, it's shorthand. It saves you several bytes in the source, saves seconds of typing, and in return rewards you with a massive headache.

I don't think that's true, just by importing the tailwind u add more bytes than plain css which you will end up writing.

Pretty sure tailwind has had the option to have the minimal CSS generated on-demand from the set of classes you actually use, for a year or so.

I haven't actually tried using this feature yet though (haven't had time to upgrade tailwind in the project where I've been using it). I suspect writing your CSS by hand could still be more efficient in per-byte output, but not enough to justify the productivity loss from not using tailwind

Re: Tailwind is a leaky abstraction

#103

Earlier quoted context omitted.

I'm a tailwind fiend, ie I like tailwind, but I can say it won't save bytes in the source if you use it the way that the docs intend. Tailwind is not very DRY so you'll probably end up repeating classes in source resulting in extra bytes if you just used a custom class repeated on similar components.

But you can create custom classes using @apply. If you're doing that alongside using it in components then it's incredibly DRY and far more efficient than anything else I've ever used in the last 20 years.

What's the difference between custom tailwind classes and... regular CSS?

Re: Tailwind is a leaky abstraction

#104
post #6

Tailwind has made building components in React an absolute joy for me. I don't need to scroll up to find my css-in-js definitions, I don't need to change windows to find the CSS modules, it's all there, in one place.

But CSS-in-JS was a mistake. Unless you want to start coupling your build tools even harder to get nonces on every compile, your CSP will require `unsafe-inline` which is bad for security. The simpler solution was to do CSS in CSS and keep your tools simple and minimal.

Re: Tailwind is a leaky abstraction

#105
post #71
post #33

Earlier quoted context omitted.

After trying out Tailwind in one pet project I have to say that for larger teams it should not be used. Looking at the code now I get the feeling that maintenance would be a big problem. A bigger project with multiple pages having full on Tailwind css classes peppered everywhere looks to be a nightmare. Does anyone have experience jumping into an existing larger project with legacy tailwind all over the place? Would…

I have only used Tailwind on personal projects, but I can't imagine it'd be harder than "regular" CSS, which is generally somewhat append-only anyway (you need a lot of team discipline to tame that somewhat). In fact, I'd expect it to be more maintainable, exactly because it removes the indirection of CSS classes. They're an abstraction that don't make much sense if you're already using components, and the very point…

This succinctly nails what I love about Tailwind. It gets rid of the cognitive load of reviewing a css change and having to think through how the change will ripple throughout the site.

Re: Tailwind is a leaky abstraction

#106
> It's essentially a small language you write in the class attributes of your HTML that compiles to a combination of CSS rules and selectors — an abstraction over CSS

That is not what abstraction means. If it is a "language" (as you describe) that essentially maps 1 to 1 of what the CSS itself does, it isn't actually abstracting anything away. The key trait of abstraction is information loss. Tailwind keeps you connected to the CSS you are using more so even than CSS in stylesheets does.

Re: Tailwind is a leaky abstraction

#107
Tailwind is awesome for those who don't know much CSS or dislike to work with CSS directly, or it is great for teams, that are not able to define general rules.

If you know CSS, you have huge problem to use a tool like Tailwind, cause you always feel like "how does this save me work?" it doesn't.

Re: Tailwind is a leaky abstraction

#108
post #47

These are fairly complex use-cases that aren't needed for 99.9% of CSS people write. In most cases I'm throwing together a handful of components in a flex container or right-aligning some buttons or something. And for that typical CSS usecase, I find Tailwind way better both for quickly iterating and for hopping into code someone else wrote. I love not having to bounce between and cross-reference 2 (or more!) files (…

> I love not having to bounce between and cross-reference 2 (or more!) files (HTML + CSS) for a description of a single layout.

Oh wow. Literally this is the exact argument I use for not using tailwind - not having my styling logic split between classes in my HTML and tailwind’s own files implementing the styles (which appears in DevTools and most other places).

Not saying either of us is right or wrong it’s just odd how different people perceive things.

Does your framework do CSS in it’s component files? If not, maybe that’s the problem?

Re: Tailwind is a leaky abstraction

#110
So we are building an all new...rather large scale product for millions of users and have been using Tailwind since the beginning of the year. In my experience writing a production app the only miss in Tailwind for me from article is the syntax for multiple properties that require the same modifiers.

writing: "p-1 md:p-3 md:text-h1 hover:md:scale-95 hover:underline hover:text-blue hover:scale-105" is super annoying compared to something like:

"p-1 text-h2 md:[p-3 text-h1] hover:[underline text-blue scale-105 md:scale-95]"

While length is still kinda long, it is far more clear what each modifier is impacting. Plus a pattern like that would discourage this mistake:

"p-1 md:text-h1 hover:underline hover:text-blue md:p-3 hover:scale-105"

Where quick work causes out-of-order classes that will produce the same result but are harder to debug due to the split off modified class.

Post reply on HN