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

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

Post reply on HN
Print view View original

111–120 of 435 posts

Re: Moving away from Tailwind, and learning to structure my CSS

#111

Post by 0x3f »

48terry wrote: post #108
0x3f wrote: post #68

Earlier quoted context omitted.

Every moment you spend doing accessibility is a moment you spend not doing other things. You could argue it has a high RoI to do accessibility, fine, but that doesn't make it lazy _not_ to do it. Maybe I have even higher RoI/EV stuff to be doing.

> Maybe I have even higher RoI/EV stuff to be doing. I mean, to readers of these comments, I think it's right there for you: 0x3f will take "higher ROI" over "accommodate and support disabled people".

Yeah, thats explicitly what I'm saying so I'm not sure it needs repeating. That has very little to do with it being lazy though, is the point.

We were already implicitly discussing RoI when we were talking about 'legal consequences' above. This is how people decide between alternatives, generally.

Re: Moving away from Tailwind, and learning to structure my CSS

#112

Post by ghurtado »

superfrank wrote: post #75
danaw wrote: post #54

Earlier quoted context omitted.

you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…

> nothing about tailwind forces you to build inaccessible or "div soup" apps Totally agree. I feel like this was more a by product of React. Not that React forced this either, but it felt like the rise in both went hand in hand for some reason. While I think it's true that none of the current top FE technologies force the div soup, they don't discourage it either. It would be nice if what ever FE technologies catch o…

Nothing about programming forces anyone to do anything.

That's never been a valid argument to dismiss criticism. It wasn't with Dreamweaver, any it wasn't with visual basic, and it isn't with Tailwind.

Patterns matter. Best practices matter. Path of least resistance matters. Those are all choices you make when you develop a CSS framework. Some of those choices are good and some are bad.

If none of those things mattered, them choosing a CSS framework would not matter at all.

Re: Moving away from Tailwind, and learning to structure my CSS

#113

Post by 9dev »

reaperducer wrote: post #38
chistev wrote: post #31

Earlier quoted context omitted.

Isn't Tailwind easy to understand when you look at the codebase, rather than putting in more effort to learn a pure CSS codebase? Isn't that part of the argument of Tailwind being easier to scale?

Isn't that part of the argument of Tailwind being easier to scale? I think that was true at the beginning. But Tailwind is quickly approaching the multi-headed hydra it was trying to replace.

What exactly has changed about Tailwind in, like, years? There are a few more properties for new CSS features, a few convenience features (like size-x instead of w-x h-x for the same values of x), but other than that? If you've grown accustomed to the utility classes eight years ago, then disappeared under a rock until today, you should be able to continue working in an unrelated, Tailwind-using project immediately.

Re: Moving away from Tailwind, and learning to structure my CSS

#114

Post by solumunus »

TonyAlicea10 wrote: post #96
danaw wrote: post #54

Earlier quoted context omitted.

you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…

If a tool’s design makes it easy to cut myself, the response is not “people have been cutting themselves for years”. There is such a thing as the ergonomics of the tool. Yes div soup has been around a long time. But also yes, Tailwind makes the wrong approach the easy one. It’s ergonomics encourage adding div elements to support styles. It’s the core design loop. You’re conflating “forces to” and “ergonomically encou…

It’s just the most effective approach, in my opinion. If it’s wrong then I don’t want to be right.

Re: Moving away from Tailwind, and learning to structure my CSS

#115

Post by 0x3f »

well_ackshually wrote: post #84
0x3f wrote: post #68

Earlier quoted context omitted.

Every moment you spend doing accessibility is a moment you spend not doing other things. You could argue it has a high RoI to do accessibility, fine, but that doesn't make it lazy _not_ to do it. Maybe I have even higher RoI/EV stuff to be doing.

Accessibility is done while you do it. Not as an afterthought. But if you're having a higher ROI writing absolute crap, feel free, it's not my website.

You're just expressing a normative view here, it's not very interesting or informationally-dense. You care about accessibility more than I do. That doesn't make not doing it 'crap'.

Re: Moving away from Tailwind, and learning to structure my CSS

#116

Post by esseph »

0x3f wrote: post #68
well_ackshually wrote: post #67

Earlier quoted context omitted.

You are lazy for not doing accessibility adjustments, because accessibility isn't for blind users. It's for the deaf ones, the ones with poor eyesight, the ones with mental deficiencies, the ones with motor issues like Parkinson's, the ones browsing your site shitfaced at 4AM, and so on and so on. Accessibility isn't a checklist to cover your ass for a percentage of the population: it's for everyone. It literally mak…

Every moment you spend doing accessibility is a moment you spend not doing other things. You could argue it has a high RoI to do accessibility, fine, but that doesn't make it lazy _not_ to do it. Maybe I have even higher RoI/EV stuff to be doing.

You just told a bunch of potential and current customers that they're not worth the ROI.

Pretty sure they'll remember that, and they'll talk about it a lot.

Re: Moving away from Tailwind, and learning to structure my CSS

#117

Post by romanhn »

JimDabell wrote: post #27

One thing that has always struck me about Tailwind is that practically every argument its proponents use more or less boils down to “I never learnt CSS beyond a junior level” . It’s super common to hear Tailwind advocates say things like “Without Tailwind, we would just have one big disorganised CSS file that always grows uncontrollably and ends up with loads of obsolete stuff in it and !important everywhere! Tailwin…

The more experienced Tailwind proponents probably have better things to do than get dragged into yet another online flamewar :) I've done tons of CSS since the 90s before looking into Tailwind. After it clicked, I've mostly tried to avoid raw CSS. In a sense, you exchange one mess for another. Personally, I'd rather deal with a localized class soup than trying to make sense of overlapping, often contradictory, cascades of styles across multiple files. Both can be implemented cleanly, but I'd much rather clean up a Tailwind mess than a CSS one. And I find the development process much more enjoyable overall.

Re: Moving away from Tailwind, and learning to structure my CSS

#118

Post by [deleted] »

0x3f wrote: post #115
well_ackshually wrote: post #84

Earlier quoted context omitted.

Accessibility is done while you do it. Not as an afterthought. But if you're having a higher ROI writing absolute crap, feel free, it's not my website.

You're just expressing a normative view here, it's not very interesting or informationally-dense. You care about accessibility more than I do. That doesn't make not doing it 'crap'.

[deleted]

Re: Moving away from Tailwind, and learning to structure my CSS

#119

Post by bumbledraven »

TFA links to https://joshcollinsworth.com/blog/tailwind-is-smart-steering, which is about Tailwind, but makes multiple distinctions and points that could just as well apply to LLMs, e.g.:

> Builders value getting the work done as quickly and efficiently as possible. They are making something—likely something with parts beyond the frontend—and are often eager to see it through to completion. This means Builders may prize that initial execution over other long-term factors.

> Crafters are more likely to value long-term factors like ease of maintainability, legibility, and accessibility, and may not consider the project finished until those have also been accounted for.

> In my view, the more you optimize for building quickly, the more you optimize for homogeneity.

Re: Moving away from Tailwind, and learning to structure my CSS

#120

Post by 9dev »

timr wrote: post #101
pverheggen wrote: post #90

Earlier quoted context omitted.

Tailwind, JS-in-CSS, and the like have become popular because they work well with the modern corporate UX workflow. A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component. There's nothing precluding you from using an approach like DaisyUI if stock Tai…

> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. This is what CSS classes were made for . Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get. > And none of this really violates DRY,…

> This is what CSS classes were made for.

That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt?

> Sure, sure. except for the inline styles everywhere.

There are no inline styles when using Tailwind. There are references to variables from the design system.

> And the fact that everything is literally being repeated all over the place.

If you find yourself repeating the same sequence of classes, it's time to create a component in your frontend framework if you use one, or a Tailwind utility class. And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely.

Post reply on HN