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

381–390 of 435 posts

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

#381

Post by isleyaardvark »

cxr wrote: post #361
isleyaardvark wrote: post #352

Earlier quoted context omitted.

This is the misconception that has caused so many problems over the years, problems that the Tailwind approach solves. There was never any separation of concerns within the HTML code, the class="" property is in the HTML and that is the styling info. Devs took the idea of separation of concerns of content, presentation, and behavior as separation of technologies: HTML, CSS, and JS, which is not the same. So they tend…

> the class="" property is in the HTML and that is the styling info The class attribute (not "property") is in the HTML because it's part of HTML. It's markup. Element classes weren't created either by or for the CSS people when CSS came along. The class attribute predates CSS by years and has no more relation to "styling info" than the id attribute does.

Yes, and that’s what it’s used for now due to the ad hoc development of HTML and CSS.

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

#382

Post by sntran »

jampekka wrote: post #260
ricw wrote: post #186

Earlier quoted context omitted.

I disagree with that conclusion. I see tailwind as a cleaner more succinct version of css that is much easier to manage and add features too. Sure it’s not as dry, but I’ve been bitten in this regard because css framework and templates are so intransparent, preventing me from simply changing padding or margin. CSS is too detailed and too verbose. Frameworks like bootstrap are too high level and don’t give enough cont…

> Sure it’s not as dry, but I’ve been bitten in this regard because css framework and templates are so intransparent, preventing me from simply changing padding or margin. How does this happen? You can always override css values. Either by ordering, !important, inline or, to make very sure, with inline !important.

When you inherit a front-end project for the Nth time, those `!important` become a nightmare.

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

#383

Post by sntran »

espadrine wrote: post #370
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…

Could you link to a project that you consider the best Tailwind use you know? I have a bias against Tailwind, admittedly because I saw some vibecoded Tailwind where each class was essentially equivalent to style="font-size: 4em; background-color: grey; display: flex;", all of which was repeated for each header. But that could be my bias; perhaps the right way to use is is DRY.

It's easy to look at one part of the HTML and see the Tailwind classes no different than inline styles.

But if you have to use `display: flex" in a lot of places, having the `flex` utility is better. And there are tons of such utilities with Tailwind.

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

#384

Post by meerita »

thiht wrote: post #196
meerita wrote: post #181

Earlier quoted context omitted.

Well, the old-school way was something like this: h1.font.size = 24pt 100%. Tailwind has its own syntax, so you need to learn it first, which adds extra cognitive load. For things like * { color: } in Tailwind, you have multiple options: text-color, stroke-color, etc. With FCSS, you simply have color--[colorname] { color: … }. It’s simpler and avoids unnecessary cognitive load.

Yeah learning syntax is not rocket science, using that against Tailwind is not a valid argument IMO

[flagged]

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

#385

Post by [deleted] »

thiht wrote: post #166
grzes wrote: post #63

tailwind is an anti-pattern that breaks separation of concerns rule. i'm amazed how it became so popular.

Because it’s a made up rule, not a law of nature. Having the styles inline on a component is very easy to reason about, it was just extremely impractical with CSS and the style attribute. Tailwind makes it easy, practical, and is actually well designed regarding its support for variables (ie. you can have a sane design system easily). What you want to share/cascade is variables, not styles. Styling components makes i…

[deleted]

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

#386

Post by cxr »

isleyaardvark wrote: post #381
cxr wrote: post #361

Earlier quoted context omitted.

> the class="" property is in the HTML and that is the styling info The class attribute (not "property") is in the HTML because it's part of HTML. It's markup. Element classes weren't created either by or for the CSS people when CSS came along. The class attribute predates CSS by years and has no more relation to "styling info" than the id attribute does.

Yes, and that’s what it’s used for now due to the ad hoc development of HTML and CSS.

What?

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

#387

Post by faefox »

amazingamazing wrote: post #289
danaw wrote: post #265

Earlier quoted context omitted.

> Sure, it's easy to overthink things but most of the time, it's not that complex. then you sir are the one that have not worked on complex projects. i'm currently the lead on a design system for a fortune 100 company with nearly 100 block level components and many other smaller elements. responsive, multi-theme/site support, animations, accessibility, robust interactivity, etc. not even a button or link is simple wh…

I have used tailwind and tachyons and they are fine. I do winder though it seems like you end up being stuck with them. How would you migrate to traditional CSS without effectively rewriting all of your css? I also wonder if it is necessary still with css modules and the fact web frameworks allow for scoped css per component.

Tailwind is just CSS so there's no lock-in to speak of and no migration necessary. If you had a specific instance where Tailwind wasn't a good fit you can just hand-write as needed.

Sure, if you wanted to stop using Tailwind altogether you would have a lot of rewriting to do but I'm not sure how that's uniquely different or worse than, say, migrating a project from React to Angular.

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

#388

Post by miyoji »

9dev wrote: post #121
timr wrote: post #70

Earlier quoted context omitted.

Yeah, that's a straw-man. I've worked on large-scale projects with many team members, and it's perfectly possible to use CSS as it was designed. But sure, like most tools, it starts with understanding how it works.

Sure it's possible, but is it possible for everyone on your team? Including the new hire, the interns, or the now-vibecoding managers? Sooner or later it deteriorates.

> Sure it's possible, but is it possible for everyone on your team? Including the new hire, the interns, or the now-vibecoding managers?

Why aren't we asking this about any of the things that are actually hard? Like any programming language, or databases, or caching... CSS is the easiest part of the web stack.

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

#389

Post by atoav »

christophilus wrote: post #259
alwillis wrote: post #135

Earlier quoted context omitted.

> tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex. > placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors In my opinion, it's the opposit…

With CSS names are global. You have to be careful not to accidentally create a class that conflicts with another one used elsewhere in a different context. You have to worry about whether modifying your class will have downstream effects on elements you weren’t intending to impact. It’s a giant pain. I’ve done it by hand for around 20 years before switching to Tailwind. Can vanilla CSS be used for a complex app? Yes.…

> You have to be careful not to accidentally create a class that conflicts with another one used elsewhere in a different context.

Has your tried using the cascading part of the language?

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

#390

Post by madkat »

efortis wrote: post #316
culi wrote: post #305

Earlier quoted context omitted.

Don't most modern CSS tools create unique class names? I know styled-components did. Recently I've been using linaria which is a drop-in replacement for styled-components (exact same API) but its zero runtime. All the CSS is compiled during build (similar to vanilla extract, panda CSS, etc). I really prefer things like styled-components or Linaria or CSS Modules where you can just write straight up CSS. If you ever d…

True, I didn't mean to omit other solutions, I thought styled-components were deprecated after React 18.

Yeah it was/is (doesn't work with server components). That's the reason we built next-yak (https://yak.js.org) as an alternative.
Post reply on HN