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

131–140 of 435 posts

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

#131

Post by HungSu »

I'm observing recurring patterns in Tailwind-only users: they learn a lot of non-transferable and bad habits, especially when the codebase scales up:

- Engineers never learn to properly use developer tools to debug CSS

- Components get gigantic bloated piles of classes that are not human readable

- Those gigantic piles of classes get logic in them, that often would have been easier to write as a CSS selector. Tailwind developers learn to write a JS ternary operator with a string of classes instead of ever learning how CSS selectors work

- Those ternary operators get too complicated. The engineers write object maps of Tailwind classes, or export consts of strings of Tailwind classes to use later. Those object keys and const names are what the CSS class names could have been if they just used CSS. They literally re-invent CSS classes, but worse.

- Tailwind classes can't be migrated. You can migrate CSS to Sass to CSS modules to Emotion CSS to etc mostly just by copying them over, because all of those are CSS (with some quirks). Tailwind classes are non-transferable

The happiest medium I've found was in an organisation of around 200 UI engineers: scoped CSS so that engineers can work with autonomy without colliding with other engineers, plus Tailwind for quick band-aid fixes.

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

#132

Post by locallost »

I wrote my first CSS 20 years ago, and one thing I can say for sure is that it's impossible to really structure your CSS in this way. The structure will break down over time and it will anyway be buggy and you'll be chasing your tail, as long as everything you do is global. It might work if you're a solo developer, but the reality is most projects involve multiple people trying to get things done. As long as a style is global, changing it will break something else. These days I use scoped styles and that's it.

My favorite is when colleague A broke something from colleague B, who fixed it but broke sometimes from me, and I fixed that and broke what colleague A did. The process repeated once more and it landed again on my desk, where I said wait a minute, I've been here already. We were than able to fix all three things at the same time.

So it's difficult to keep track of everything.

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

#133

Post by outlore »

IMO the killer feature of tailwind is that it lives alongside your React components so you keep things DRY, and you get a design system with type and spacing scales out of the box. It’s a form of constraint that helps create structure. But I think that makes it a victim of its own success. The tailwind spec becomes ever more complicated the more native CSS features it tries to include. I’ve seen tailwind incantations go way beyond editor wrap line

I still like it though. it’s one of those abstractions that actually helped me learn. I would go to the tailwind doc pages and see the underlying css of any class.

There were some other frameworks I got excited about: vanilla extract and stitches, both made by some really talented people. I wonder why those never quite got the same traction…

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

#134

Post by Sankozi »

codethief wrote: post #124
arealaccount wrote: post #122

Earlier quoted context omitted.

I’ve mentioned this before here, but originally I was against Tailwind because it breaks the Cascading part of CSS, however I think a lot of websites lately work better with “locally scoped” styles as there are just so many different components that many things just dont need to follow a global style sheet. So now I usually reach for tailwind first, unless is a relatively simple vanilla html site

Global styles are like global state in software: They're best avoided.

So no CSS files at all? Only inline styles?

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

#135

Post by alwillis »

danaw wrote: post #54
TonyAlicea10 wrote: post #3

> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…

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…

> 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 opposite. Besides the obvious violation of DRY and the separation of concerns, inline CSS can't be cached and it creates a lot of noise when using dev tools for debugging. It actually increases cognitive load because you have to account for CSS in two different locations.

Lots of people use Tailwind because they don't want to deal with the cascade, usually because they never learned it properly. Sure, back in the day, the web platform didn't provide much built-in support for addressing side effects of the cascade, but now we have @layer and @scope to control the cascade.

Tailwind uses a remnant of '90s web development (inline CSS) and built an entire framework around it. I get why it appeals to some people: it lets you use CSS while not requiring an understanding of how CSS works, beyond its most basic concepts.

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

#136

Post by pverheggen »

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

There are a bunch of differences between Figma styles and CSS styles that prevent you from creating a 1:1 mapping: typography inheritance, spacing rules, and variant specificity to name a few.

Like yes, CSS by itself is extremely powerful, but I see no reason why you should feel beholden to use all of its features simply because they're there.

> Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition!

Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.

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

#137

Post by TonyAlicea10 »

zero_shift wrote: post #59
TonyAlicea10 wrote: post #13

Earlier quoted context omitted.

This isn't about "purity/correctness" it's about the real experience of a blind person. Accessibility means caring about the HTML. Your comment only mentions developers as the audience of HTML authoring, as opposed to users, which is a common attitude and the core problem with Tailwind.

What does Tailwind have to do with accessibility? Most significant HTML markup is block level elements. The CSS is completely orthogonal. I feel like old-school frontend devs bring up accessibility as a kind of bogeyman. It reminds me of the myth that CSS style X or Y breaks accessibility "because screen readers expect semantic CSS classes". Zeldman (of A List Apart) promulgated that disinformation for years, until s…

It’s not Tailwind the tech, it’s the ergonomics of the tool. Tailwind’s design loop encourages “let me add a div so I have a place for my CSS class”.

I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design.

Basic HTML authoring is good practice for many reasons.

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

#139

Post by Muromec »

villgax wrote: post #2

Relying on React or Typscript in LLM era seems very stupid, just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop. Far more offline compatible development almost negligible supply chain issues as well. At least ones you can control.

Why write in rust if LLM can write assembler for any architecture?

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

#140

Post by TonyAlicea10 »

vehemenz wrote: post #15
TonyAlicea10 wrote: post #3

> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…

A few counterpoints: Treating markup and styles separately is great, in principle, but you'll always need additional markup for certain things. We knew this going back to the early 2000s. There is nothing about Tailwind itself that forces you to use divs and spans instead of the appropriate HTML tag. Documents and interfaces are different. Tailwind makes a lot more sense for interfaces. You can use Tailwind for the i…

Folks in this thread keep conflating “forces to” and “ergonomically encourages”.

If a power tool is poorly designed it may not force me to hurt myself but if it makes it easier that’s a problem.

Post reply on HN