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

CSS's problems are Tailwind's problems

colton.dev

Post reply on HN
Print view View original

121–130 of 179 posts

Re: CSS's problems are Tailwind's problems

#121

Post by dcre »

wuz wrote: post #57

Tailwind has taken the world by storm because it let's engineers completely ignore actually learning the technology that powers the web. That doesn't make it good - and it isn't. It's a bloated mess with tons of random technology surrounding the ecosystem in an attempt to make it usable. Tailwind literally only becomes usable for large scale applications once you have combined base tailwind, postcss, a number of tail…

The idea that Tailwind prevents you from learning CSS has always been very silly because Tailwind is CSS. You cannot learn Tailwind without learning a lot of CSS. The Tailwind docs are the most concise and practical CSS docs around.

Re: CSS's problems are Tailwind's problems

#122

Post by darepublic »

jmuguy wrote: post #117

It would be helpful to link to the Tailwind section about duplication https://tailwindcss.com/docs/styling-with-utility-classes#us... As someone that used Tailwind for years at this point, you're right about why its so popular. To me it was just a better version of Bootstrap. Its defaults look nice, its color choices are nice. I would also mention that their docs are top notch and Tailwind UI makes it really to just…

Setting up the tooling around tailwind is more a pita than vanilla CSS imo. If you are using tailwind just for the nice default styles there are already myriad simpler solutions for that. Comparing the use of vanilla CSS to.. writing in C, I don't get it.

Re: CSS's problems are Tailwind's problems

#123

Post by vehemenz »

> Tailwind does nothing to reduce the mental load on your developers to understand, read, and write in your codebase. In fact it does the opposite. Your developers are not spared the hassle of learning CSS by instead learning tailwind's abstractions. Developers have to understand not just that background-color is the CSS key to set a background color, but they also must understand that classes prefixed with bg- mean background color. Every feature of CSS, such as media and container queries, will need to be learned twice, CSS style and Tailwind style.

Just wrong. The whole point of 1:1 style:class mappings is that you don't have hidden structures relating the DOM to your stylesheet's class abstractions.

If you're going to talk overhead, talk about all the abstractions and hidden structures you have to learn in a codebase written in the "correct" way to do CSS. It's just incomparable.

Tailwind's class names are trivial to learn for anyone that already understands CSS. It's minimal overhead compared to learning CSS. "Learning it twice" is completely inaccurate.

Re: CSS's problems are Tailwind's problems

#124

Post by vehemenz »

mejutoco wrote: post #91
micromacrofoot wrote: post #6

Earlier quoted context omitted.

I can't believe people find even half of this acceptable, do they never use a browser inspector in their work?

There was a time when not having css and html completely separate was considered sacrilege. And having html in javascript would have been a mortal sin. Eons ago I was at a job where we dynamically generated css on the server (php in that project). Anyone would have said: what about separation of concerns? Now everyone says it is best practice to have components with css, html and (gasp) Javascript all in one unit, be…

The thing is, they were never really separate. The source files were separated, sure, but the way 90% of the world did CSS, there were hidden abstractions relating the class definitions in the .css file and the DOM structure in the .html that weren't documented anywhere.

Re: CSS's problems are Tailwind's problems

#125

Post by H1Supreme »

9dev wrote: post #86
squidbeak wrote: post #61

Earlier quoted context omitted.

There's a big difference between using utility classes for utilities and using utility classes for everything.

And here we’re on firm bike-shedding territory. Where does a utility stop being a utility and start being… a non-utility?

It's less of when it becomes a "non-utility", and more that it becomes an incomprehensible mess of classes on a div.

Re: CSS's problems are Tailwind's problems

#126

Post by omnimus »

hombre_fatal wrote: post #68

Since Tailwind looks obviously bad on first pass with all the class spam, I'm more curious to see someone steelman Tailwind. I have some ideas, like how the dead code elimination + granular but consistent classes lets you build novel components that are still consistent with your UI which might be essential for making a 3rd party component library work. I've been using Bootstrap since it came out 15 years ago but it…

I think the tricky part is that Tailwind (and other functional css frameworks) are loved by 1. complete noobs who dont know css and 2. absolute killer css devs in agencies making content sites.

Most devs on this website work on aplications in big teams maintaining projects for years where css is component scoped and there is time and there are quality checks.

Now when you work in agency you come to a extremely visualy complex product website or magazine. You haven’t seen the codebase for a year (or never) and you need to change little thing and add new section to homepage… all without breaking any other part of the website. And while you have 5 hours budget.

In that context Tailwind is best middleground. It establishes system to follow and it is selfdocumenting. Everyone who can read tailwind instantly knows whats going on. And it is much better than inline styles because you can make it responsive and not get to specificity hell.

People here bash funtional css thinking that those who like it don’t understand css. I’ve worked both in agencies and on products and sorry writing css for a CRUD app forms is piece of cake compared to css for beautiful product site where every part is unique and you are required to have deep understanding of how browsers render so you can exploit that inverted position sticky so some ui cards align just right in performant way.

What i am saying is there are many kinds of websites and people who like Tailwind might just be in very different situation and sometimes they might even know way more css than those who hate it.

Re: CSS's problems are Tailwind's problems

#127

Post by zaphar »

roguecoder wrote: post #101
lenkite wrote: post #4

If you go even minimally outside the beaten path, the tailwind CSS declarations can mutate into a frankenstein monster that makes regular CSS look like a friendly, cute koala Example: https://www.nikolailehbr.ink/blog/realistic-button-design-cs... shows an "old fashioned", 90's are back-in-vogue, 3d button. Tailwind CSS for it becomes After I got eye-strain and headaches after taking over maintenance of a tailwind ba…

The power of CSS is that it can capture semantics. Tailwind gives up on all of that.

What? Since when did CSS become about capturing semantics? That's what the Html elements are for. CSS is about the presentation.

Re: CSS's problems are Tailwind's problems

#128

Post by pluto_modadic »

crowcroft wrote: post #22
lenkite wrote: post #4

If you go even minimally outside the beaten path, the tailwind CSS declarations can mutate into a frankenstein monster that makes regular CSS look like a friendly, cute koala Example: https://www.nikolailehbr.ink/blog/realistic-button-design-cs... shows an "old fashioned", 90's are back-in-vogue, 3d button. Tailwind CSS for it becomes After I got eye-strain and headaches after taking over maintenance of a tailwind ba…

Is that more or less verbose than button { position: relative; cursor: pointer; overflow: hidden; border-radius: 0.375rem; border: 1px solid #0a0a0a; background-color: #171717; padding: 6px 12px; color: #f5f5f5; box-shadow: inset 0 1px #525252, 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1); transition: all 150ms cubic-bezier(0.4, 0, 0.2, 1); } button::before { content: ""; position: absolute; inset…

1. highlighting

2. syntax checking

3. language servers.

Re: CSS's problems are Tailwind's problems

#129

Post by vehemenz »

crowcroft wrote: post #22
lenkite wrote: post #4

If you go even minimally outside the beaten path, the tailwind CSS declarations can mutate into a frankenstein monster that makes regular CSS look like a friendly, cute koala Example: https://www.nikolailehbr.ink/blog/realistic-button-design-cs... shows an "old fashioned", 90's are back-in-vogue, 3d button. Tailwind CSS for it becomes After I got eye-strain and headaches after taking over maintenance of a tailwind ba…

Is that more or less verbose than button { position: relative; cursor: pointer; overflow: hidden; border-radius: 0.375rem; border: 1px solid #0a0a0a; background-color: #171717; padding: 6px 12px; color: #f5f5f5; box-shadow: inset 0 1px #525252, 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1); transition: all 150ms cubic-bezier(0.4, 0, 0.2, 1); } button::before { content: ""; position: absolute; inset…

There is also additional risk by overusing CSS's built-in selectors and inheritance, whereas there's zero risk with Tailwind.

Re: CSS's problems are Tailwind's problems

#130

Post by wg0 »

crowcroft wrote: post #22
lenkite wrote: post #4

If you go even minimally outside the beaten path, the tailwind CSS declarations can mutate into a frankenstein monster that makes regular CSS look like a friendly, cute koala Example: https://www.nikolailehbr.ink/blog/realistic-button-design-cs... shows an "old fashioned", 90's are back-in-vogue, 3d button. Tailwind CSS for it becomes After I got eye-strain and headaches after taking over maintenance of a tailwind ba…

Is that more or less verbose than button { position: relative; cursor: pointer; overflow: hidden; border-radius: 0.375rem; border: 1px solid #0a0a0a; background-color: #171717; padding: 6px 12px; color: #f5f5f5; box-shadow: inset 0 1px #525252, 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1); transition: all 150ms cubic-bezier(0.4, 0, 0.2, 1); } button::before { content: ""; position: absolute; inset…

To each their own, the Tailwind version is more readable for me.
Post reply on HN