Live data from Hacker News

Tailwind is a leaky abstraction

jakelazaroff.com

91–100 of 391 posts

Re: Tailwind is a leaky abstraction

#91
post #54
post #35

Earlier quoted context omitted.

Styling HTML with a few classes and css selectors has drawbacks: you have tightly coupled code that is separated, and modifying one or the others implies that you recalls properly its counterpart. There are methodologies trying to address that, but it never seems to be enough helpful. This becomes even harder when you refactor/reuse things. It is then worse when you want to maintain. With an approach like tailwind, w…

Other than being shorter, what's the benefit of Tailwind over style attributes on HTML tags? (I am no frontender, though I was a "full stack developer" up to CSS 2.0)

> what's the benefit of Tailwind over style attributes on HTML tags

For example, you can't specify hover, focus etc. style attributes. You can't specify screen sizes either. Plus there are few Tailwind classes that cover several attributes.

Plus many of those styles are just unwieldy. For example, `drop-shadow` is `filter: drop-shadow(0 1px 2px rgb(0 0 0 / 0.1)) drop-shadow(0 1px 1px rgb(0 0 0 / 0.06));`

Re: Tailwind is a leaky abstraction

#92
let's not forget the HN mob is mostly back-end devs who will cheer for anything that gives them a quick and dirty way to style websites. These people have never needed to maintain a front-end codebase nor think about design systemically.

Re: Tailwind is a leaky abstraction

#93

Is making a CSS abstraction the primary goal of tailwind? With my limited understanding, isn’t the main point to use a compact DSL to stop separating style into a different file, therefor ending the scourge of ever-growing stylesheets? No abstraction is going to address 100% of the underlying concept, but that doesn’t mean it’s not useful. I’m on a team that is currently fawning over Tailwind. I am extremely skeptica…

Many have suggested that Tailwind is some kind of replacement for knowing CSS, but I'm extremely skeptical of that idea.

I'm a fan of Tailwind, and use it a lot. There's no way you can use it effectively without knowing CSS. Contrary to the original articles statements, it's not really an abstraction. It has some very very minor abstractions like `space-between`, but these are the exception rather then the rule. Most of Tailwind lines up 100% with one specific rule in CSS. You have to know CSS to use it.

Re: Tailwind is a leaky abstraction

#96

Agree 100%. I wish there was a lightweight utility framework that is truly just shorthand, i.e. if I know the CSS property I can predict what the class name would be. With Tailwind it's all arbitrary

Are you using a code editor plugin that surfaces the correct classes? There's no guess work involved.

My plugin supports this, but only if I happen to know the shortcut. When I start typing...

  border-radi
...for example, the plugin doesn't suggest...

  rounded
...because I didn't type anything close to matching that.

It seems like the only way to benefit from Tailwind without having to switch between your file and the docs is to invest time memorizing the many, many, many shortcut classes that don't start with the same word or letters as the actual CSS property name you already know.

Re: Tailwind is a leaky abstraction

#98
post #67

Earlier quoted context omitted.

Performance, brevity. TW classes are a lot more concise and provide a "design system" vs raw values and browsers are good at applying classes vs parsing inline styles for every element.

I am really curious about the performance claim. It seems to be mostly a matter of where the performance penalty is paid. Browsers either parse CSS (mostly) "ahead" of HTML (tailwind CSS classes), or as they parse HTML (inline CSS): they still got to parse a very similar amount of CSS, except if you've got the same "rule" applied in a number of places (though in that case, element-based CSS rules probably win-out). D…

first google result https://www.sderosiaux.com/articles/2015/08/17/react-inline-...

> parse HTML (inline CSS): they still got to parse a very similar amount of CSS,

I have no idea how it works but I imagine there is a difference to

    parse class.css
    parse el1.html
     apply class to el1
    parse el2.html
     apply class to el2
vs

    parse el1.html
     parse el1.css
     apply style to el1
    parse el2.html
     parse el2.css
     apply style to el2
Honestly the argument pro/con performance is irrelevant to me, writing this 100 times

  class="text-lg"
is immeasurably more ergonomic than writing this 100 times

   style="font-size: 1.125rem; line-height: 1.75rem;"
Or even worse

   class="shadow"
and

   style="box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1)"
and that's only one style.

Re: Tailwind is a leaky abstraction

#99
>Tailwind is a Leaky Abstraction

Yes! Yes it is! And that doesn't matter a single hoot! Go and write your complex CSS to do your perspective shenanigans, that's absolutely fine. Don't be a purist who MUST HAVE UTILITY CLASSES AND ONLY UTILITY CLASSES. And you can't, and shouldn't, write tailwind while being ignorant of CSS.

You've set up a strawman and knocked it's head off, but I can clearly see you boxed a scarecrow.

Tailwind is not a CSS revolution, it's just a slightly easier way of writing (and learning!) responsive/interactive CSS. That's it. The hype is just that it actually fulfills that brief.

Re: Tailwind is a leaky abstraction

#100

We have used a similar css utility library (Atomizer) at Yahoo for 8+ years. This has been used across many sites with a large group of developers touching the code. It has saved a ton on CSS size and duplication. We never force only atomic classes, for more complex use cases we push developers to write vanilla CSS. Some of his points are valid about maintainability and complexity, but that can be resolved by buildin…

This comment really helps illustrate how we are always reinventing the same tools in web development.
Post reply on HN