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

331–340 of 391 posts

Re: Tailwind is a leaky abstraction

#331

Post by TylerE »

verisimilidude wrote: post #254
viddi wrote: post #119

Earlier quoted context omitted.

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.

That was back when XML was supposed to take over the world. We were going to style the same semantic content for print and web with CSS and/or XSLT. XHTML was the next big thing. Every web page was actually just a page. We're not living in that future. But the CSS ecosystem is still useful, and still adapting to our needs today. Tailwind might be considered one of those adaptations.

The sad thing is, the one good thing to come out of that swamp (xpath) isn’t used nearly widely enough.

Re: Tailwind is a leaky abstraction

#332

Post by mixmastamyk »

HelloNurse wrote: post #191
yurishimo wrote: post #114

Earlier quoted context omitted.

I think Adam Wathan's (the creator of TW) article [0] sums up the issues you are likely having. Modern CSS has an inherent dependency on the structure of your markup. This is a newer byproduct of modern design. Back in the day, you'd add something like `a { color: orange; }` for your entire site and be done with it. As sites got more complicated and design became a feature rather than an afterthought for websites, ou…

This kind of "colocation" doesn't scale too well: a family of as little as two pages should share a stylesheet for their common classes, ids and common structures, not consistently repeat identical CSS in multiple files. The common technique of defining components encapsulating related markup and CSS makes repetitions in the output pages harmless because they are write-only, but it only moves the problem one abstract…

Keep globals in globals, locals in locals.

Re: Tailwind is a leaky abstraction

#333

Post by snarkyturtle »

confidantlake wrote: post #321

I don't really get Tailwind. Whenever I am looking at a layout, I am doing it in the inspector tools, not in the stylesheet or the html file. I don't care if the class is called top_bar or foo_bar or if the styling is done inline. I do care that is had a border-radius of 10px,. With tailwind I have to somehow know that border-radius is supposed to be "rounded". I have to learn a whole new language and constantly tran…

Except you should be learning a "language" anyway because that's what building a product is about.

To use your "rounded" thing as an example:

Design systems should have their own definitions of what a "rounded" thing is. The designs also probably have different types of border-radius based on if it's a container element, or a button, or a pill button, etc. So you define those as different types of "rounded". Small, medium, large. Round, rounder, roundest. They could be whatever you want. This way, your team doesn't have to remember that 10px = round, designers or PMs just say "round" and you use the "round" utility class.

Or if they don't like styling they can say "hmm what about 'rounder'?" and you use the rounder class.

That's what Tailwind aims to solve is to 1) define a common language across the team and 2) make that easily available for the FE dev to implement versus trying to cross-reference what "round" is.

Re: Tailwind is a leaky abstraction

#334

Post by danielvaughn »

robacarp wrote: post #329
confidantlake wrote: post #321

I don't really get Tailwind. Whenever I am looking at a layout, I am doing it in the inspector tools, not in the stylesheet or the html file. I don't care if the class is called top_bar or foo_bar or if the styling is done inline. I do care that is had a border-radius of 10px,. With tailwind I have to somehow know that border-radius is supposed to be "rounded". I have to learn a whole new language and constantly tran…

> I have to somehow know that border-radius is supposed to be "rounded". Yeah I agree with you there. If you're writing tailwind you have to constantly have the tailwind docs site open.

There's a tailwind intellisense plugin. Just type something into a class string and a bunch of suggestions pop up. Makes it incredibly easy - I learned nearly all of Tailwind in like 2 hours this way.

Re: Tailwind is a leaky abstraction

#335

Post by hello1234567 »

there is a different way to achieve the same results. instead of encoding every possible rule into classes, a combination of flex box-classes, templating and text props could be used.

there is some repetition, but it will keep things simple.

same thing for spacing example, have a margin prop on a flex box container and apply it on each container then wrap them into a flex container.

it will be easier compose to compose vs css class variation.

Re: Tailwind is a leaky abstraction

#336

Post by root_axis »

sfvisser wrote: post #240
onion2k wrote: post #230

Earlier quoted context omitted.

After enough of these, you get annoyed. If they're typical things that you'd expect a library to solve, sure. If they're "I want my element to rotate in 3D" then most developers would think they're just working outside of the scope of the library.

Libraries that have a scope defined implicitly by what accidentally works or doesn’t work can still be very annoying.

Based on this reasoning, C is a leaky abstraction because you can inline asm into a C program.

Re: Tailwind is a leaky abstraction

#337

Post by jacobsenscott »

CSS has done more damage to developer productivity than any other technology out there. And I'm including .csv's. CSS is over 20 years old and we as an industry have been spinning our wheels on how to do simple arrangements of rectangles the whole time. Truly, it is time to just bin the whole thing as a failure.

Re: Tailwind is a leaky abstraction

#338

Post by Zpalmtree »

HelloNurse wrote: post #191
yurishimo wrote: post #114

Earlier quoted context omitted.

I think Adam Wathan's (the creator of TW) article [0] sums up the issues you are likely having. Modern CSS has an inherent dependency on the structure of your markup. This is a newer byproduct of modern design. Back in the day, you'd add something like `a { color: orange; }` for your entire site and be done with it. As sites got more complicated and design became a feature rather than an afterthought for websites, ou…

This kind of "colocation" doesn't scale too well: a family of as little as two pages should share a stylesheet for their common classes, ids and common structures, not consistently repeat identical CSS in multiple files. The common technique of defining components encapsulating related markup and CSS makes repetitions in the output pages harmless because they are write-only, but it only moves the problem one abstract…

> a family of as little as two pages should share a stylesheet for their common classes, ids and common structures, not consistently repeat identical CSS in multiple files.

Why?

Re: Tailwind is a leaky abstraction

#340

Post by wokwokwok »

horsawlarway wrote: post #324
admax88qqq wrote: post #309

Earlier quoted context omitted.

Yes tailwind let's you reach through and apply some CSS directly. Almost like its an abstraction that exposes, or leaks, that which it attemps to abstract. A "leaky abstraction" if you will.

Honestly - I find this opinion misguided. It's like saying a for loop is a leaky abstraction over a while loop. Which... is asinine. One is simply a redacted and simplified expression of the most common implementation of the other case. Tailwind falls into the same bucket - in my opinion. Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into…

I think the opinion here comes from other compile-to-x languages.

Let’s look at typescript, or sass. There is (afaik) no construct in the underlying js or css that cannot be represented using them.

You could conceivably never learn javascript, learn typescript and basically be fine.

So when people say “leaky abstraction” they seem to be assuming that tailwind, which is a framework will allow you to represent every possible css output.

…which it can’t do, obviously, and was never intended to do.

All I’m pointing out is that the expectation that it could might not be quite so daft when viewed from the lens of “I expected tailwind to be a framework in the same way sass is” or perhaps “the same way this framework that compiles using sass is”.

It’s like if I was using vue, and found that the template language can’t express complex logic without writing js (h() expressions) and not using the template language at all.

It’s wrong to say it’s a leaky abstraction; but it’s maybe not completely asinine to say, it a bit rubbish that you have to do that as soon as you hit any non trivial use case…

> Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases.

…but as you say. Quite so. Im just saying I can see the frustration people encounter when they have the naive expectation that those edge cases are rare enough they’ll never hit them, and then immediately run into them.

Post reply on HN