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

Tailwind is a leaky abstraction

jakelazaroff.com

Post reply on HN
Print view View original

151–160 of 391 posts

Re: Tailwind is a leaky abstraction

#151

Post by hbn »

theturtletalks wrote: post #128
hbn wrote: 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 (…

Tailwind is honestly great for beginners since it "simplifies" CSS into short-hand classes. The people that know CSS don't want to learn new classnames when they can use CSS and that is a standard. I'm personally scared of forgetting CSS if I use Tailwind extensively. I also don't like the aesthetic of all the classnames being bunched together, but Tailwind does have value.

I should clarify, I wasn't a beginner when I started using Tailwind. I already had frontend experience, it's just my current job already had started using Tailwind in all their webapps before I started.

I don't think Tailwind is the place to start learning CSS. Tailwind is just a more efficient way to write CSS, and you should be aware of what's going on under the hood. It doesn't mean if you're writing your CSS in Tailwind you're never gonna look at normal CSS. There's plenty of times when I'm iterating on a design and I'll hop into the "Styles" section of my console and directly edit the element.style{} section, writing normal CSS to mock something out before translating it back into Tailwind in my editor.

So I certainly haven't forgotten normal CSS names. Not to mention the Tailwind names generally match up pretty closely with the underlying CSS names. It's only minor translations to go between the two, and maybe a special case here or there. The documentation[1] is very good with a quick search can type CSS or Tailwind names into to find what you want, and it'll show both the Tailwind name and the CSS attributes/values it outputs so I tend to keep that open in a tab while I work.

[1] https://tailwindcss.com/docs/

Re: Tailwind is a leaky abstraction

#152

Post by gedy »

candiddevmike wrote: post #103
solumunus wrote: post #77

Earlier quoted context omitted.

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?

Or Bootstrap, etc. This is why we didn't end up using TW for a large production app. It's really cool, but realized we were just ending up re-creating something like Bootstrap components using TW @apply.

Re: Tailwind is a leaky abstraction

#153

Post by dageshi »

viddi wrote: post #119
adamlett wrote: post #26

> But that's kind of the point. Tailwind is a layer on top of CSS, but it doesn't actually hide any complexity in the layer below. You still need to know CSS. This completely misses the point of Tailwind. The point is not to hide the complexity of CSS, but to provide access from the markup to enough of capabilities of CSS that you don't have to edit your stylesheets 95% of the time, when you alter the styling of a do…

Maybe I'm going out of a limb here, but wasn't the whole point of CSS to not have to touch the markup when changing the styling? Not trying to talk Tailwind down, I have just missed a lot of the evolution of web design in the past 15 or so years.

Everything on the web became a lot more dynamic. Stuff like web apps obviously but even relatively straight forward info pages end up with dynamic filtering and elements of app like functionality often.

Given that, the separation becomes more of a pointless burden than actually doing anything useful.

Re: Tailwind is a leaky abstraction

#154

Post by mikl »

The utility class shorthand is nice for simple things. But there’s definitely a “too much of a good thing” point, where the “shorthand” becomes so complex that you’re better off writing proper CSS instead, whether as inline styles or in a separate .css file.

I think that’s the main failing of the Tailwind crowd, they want to “Tailwind all the things”, use their shiny new hammer for everything, even for things where it’s clearly not the best tool, like crochet.

Re: Tailwind is a leaky abstraction

#155

Post by pcthrowaway »

faebi wrote: post #15

Sometimes I wonder why we don‘t use inline css more often instead of tailwind.

You'd end up with much larger source.

Imagine you have a React component you render once for each element of a JSON array:

    products.map((product) => (
      {product.name}
    ))
which would be the equivalent in tailwind of doing

    products.map((product) => (
      {product.name}
    ))
In this case, the `class="text-amber-700` attribute isn't going to be much different in size than `style="color: rgb(180 83 9)"`, but tailwind has other utility classes such as ".grid-cols-3" which would be equivalent to an inline style of "grid-template-columns: repeat(3, minmax(0, 1fr));"

It also lets you set up a minification pipeline which turn the "text-amber-700" example above into something like

    .xJ2Xa9 {
      color: rgb(180 83 9);
    }
    ...
    Awesome product #1
    ...
I'm sure you could minify inline CSS similarly, but I suspect the tooling there isn't as polished.

Re: Tailwind is a leaky abstraction

#156

Post by naasking »

grose wrote: post #40

Tailwind is 100% an antipattern, spitting in the face of well-written CSS. It is essentially a crystallization of the 'utility class abuse' anti-pattern. There is already a well-defined way to write CSS inline, no need to obscure it with 'helpful' utility classes... right? In reality, I don't think that's necessarily a bad thing. When Rails came out, people ranted about how PHP was bad practices because it mixed disp…

> There is already a well-defined way to write CSS inline, no need to obscure it with 'helpful' utility classes... right?

Inline CSS doesn't support lots of CSS that is critically important, like media queries, pseudo selectors, etc. That's the big reason why inline CSS should generally be avoided. There's nothing intrinsically wrong with it otherwise.

You're almost certainly using a templating language to generate your markup anyway, so if you're worried about the need to repeat common styles then factor out the common style declarations into shared variables in your template language. Yes, it's a way to avoid writing CSS, but look what it gets you: you've reduced the number of languages and files you have to manage and context switch between when developing. Typically this is programming language + template markup language + HTML + CSS + JS.

Eliminating 20% of your cognitive overhead is nothing to sneeze at. You can add something like htmx and remove most of the JS too for a 40% reduction. Front-end development actually starts approaching something close to pleasant.

Re: Tailwind is a leaky abstraction

#157

Post by grose »

pcthrowaway wrote: post #118
grose wrote: post #82

Earlier quoted context omitted.

You (and super256) are right. You do need to understand CSS to use Tailwind well, which is more or less the point of this article. I should have probably said "it's for people who don't want to deal with cascading", but IMO cascading is CSS's most powerful property. I can see how it gets confusing though.

Cascading is also why CSS becomes so unmaintainable

I think that's a fair take. Tailwind and css-in-js's popularity points to a mismatch between how people want to actually use CSS and how CSS was designed to be used. It looks like people want isolated components, not complex cascading hierarchies.

I think that when :has becomes viable, we will open to the door to CSS-driven declarative UIs as opposed to imperative JS components, but this is pure speculation :-). I believe that a development style that takes advantage of cascading instead of fighting against it could perhaps become one of the new 'schools' of frontend development. I do not think it will become the most popular one, though.

Re: Tailwind is a leaky abstraction

#158

Post by necovek »

bongobingo1 wrote: post #98
necovek wrote: post #67

Earlier quoted context omitted.

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 Hones…

That benchmark tests something slightly different with a focus on repeated CSS rules (and all from JS even): it's not surprising that's faster, though it's interesting it's faster even from JS (I acknowledged expecting that, and that CSS rules per HTML element are likely even faster, eg. a td rule with all the styles on it would probably win over that too).

I do get the terseness point, but unless you are completely happy with Tailwind definitions, it makes code less maintainable rather than more IMHO: instead of having a familiar place to look up the "shadow" definition (if that's not really doing what you want) in your own CSS or HTML file, you need to look at tailwind CSS inside your dependencies, or inside a debugging console in your browser.

I am also unhappy about any code where you'd have to write even `class="text-lg"` a 100 times: perhaps I am still living in the foolish dream of semantic markup, and I would hope you can structure your document in a way where styling is context-dependent: so perhaps you put class="text-lg" on an "top-level" element, and then only adjust nested element text sizes where needed.

Re: Tailwind is a leaky abstraction

#159

Post by agloeregrets »

enraged_camel wrote: post #23

I used Tailwind for a year at work, never having used it before. I found it overrated, frankly, and not much of an efficiency boost. We had a "don't use inline styling or your own CSS classes if a Tailwind class already exists" rule. While the reasoning was understandable, it meant that every time I wanted to style or position a component, I had to browse the Tailwind docs to make sure I wasn't duplicating something.…

We found that the tailwind VScode plugin was hyper helpful along with cutting down the unneeded in tailwind.config. Once you do that, most styling and positioning is variations on sizing, colors, and text sizes. Then the intellisense is pretty helpful to fill in the rest, some gotchas of course. `leading-` is an awful name for line spacing lol. A hardcore knowledge of CSS and all the governance you would use in vanilla is required to use tailwind however. It is important to see it from that angle.

What seemed to help us (and I don't condone this for everyone, it just worked for us) was to go more extreme: No CSS without a bulletproof defense in a PR. The only exception we needed to break in our large scale platform was to style an SVG progress indicator with complex gradients. Angular's behavior around [ngClass] not just adding classes but removing them also was a bit tricky. Personally the behavior in whole feels like a bug but I know it isn't.

Re: Tailwind is a leaky abstraction

#160

Post by gemstones »

nailer wrote: post #116
o_m wrote: post #28

Earlier quoted context omitted.

I view it as a subset of CSS that removes the bad parts of CSS

You could just use that subset of CSS though. If fact it’s a genuinely good idea to do so. Grid first, using paddings and gaps can do almost everything you can draw 1:1 without hacks. No margins, no clear fixes, no floats needed.

There's a meaningful difference to my workflow of doing
versus doing

    .mycomponent__wrapper {
      padding: 0 1rem; // Don't forget the time to look up whether it's vertical | horizontal or horizontal | vertical because I forget all the time
    }
then
and toggling between files, and making sure the team knows my preferred CSS layout structure in the general case. Plus, the solution for more complicated CSS is to just write it as CSS and to add the class directly like you would before. The point of tailwind is that I don't actually like or care about knowing CSS trivia, I just happen to know it. There's no value to me in doing things directly in CSS unless it's complicated enough to justify going to that layer. A helper layer is perfectly fine.
Post reply on HN