Moving away from Tailwind, and learning to structure my CSS • Hacker News Board

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

#411

Post by 4rt » Mon, May 18, 2026, 11:51 AM UTC

danaw wrote: post #265

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…

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

if you're writing class="flex-inline width-30 font-large" it's even worse than inline css because it has an abstraction layer and dependencies.

just write css, tailwind has always been total junk.

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

#412

Post by 4rt » Mon, May 18, 2026, 11:59 AM UTC

jakelazaroff wrote: post #320

the_other wrote: post #267

Earlier quoted context omitted.

> With CSS names are global. In your "programmatic" code (your JS/TS, python, C++, whatever..) your classes are global. Even if the language supports flexible namespaces, or module scoping, you still have to take great care naming because reusing a name will cause you confusion. Giving two things the same name makes them harder to import, and risks clashes and bugs. No-one complains about this. This is just how you c…

In "programmatic" code, declaring two classes with the same name in the same namespace is generally either some sort of syntax error or one will "shadow" the other; it doesn't just silently merge the behavior of both classes .

the 'silent merging' you're talking about is the c in css

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

#413

Post by kirtivr » Mon, May 18, 2026, 3:21 PM UTC

A less known hack that can help people build professional websites that do not have the crazy gradients, wonky logos, typography and other tell-tale signs of being LLM generated:

Get the TailwindCSS lifetime membership. Costs about $50 if I remember correctly, but they give you all the UI blocks and CSS components, and then you can simply create a frontend-design skill based on Claude's (https://github.com/anthropics/claude-code/blob/main/plugins/...) that instructs the coding agent to only use TailwindCSS catalyst and UI blocks (you'll have to download these).

This is how I built my own website.

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

#414

Post by alwillis » Mon, May 18, 2026, 7:47 PM UTC

funksta wrote: post #242

alwillis wrote: post #155

Earlier quoted context omitted.

It's unfortunate Inverted Triangle CSS (ITCSS) isn't more popular. Instead of resisting the cascade, it embraces it and makes it work for the developer. The summary: write your CSS in specificity order [1]: /scss/ ├── 1-settings. ITCSS basically does away with specificity wars in a CSS codebase. Usually the only place !important is the utility layer. [1]: https://matthiasott.com/notes/how-i-structure-my-css

Aren't Cascade Layers [1] a more reliable, native solution to the specificity problem? In 2026, why not lean on them instead of source order? [1] https://developer.mozilla.org/en-US/docs/Learn_web_developme...

> Aren't Cascade Layers [1] a more reliable, native solution

Like many new-ish CSS features, adoption is low; around 4-5% from a crawl of 17 million sites [1]. It's been available in all major browsers since 2022.

I'm generally addressing developers who are never going to use any (or very little) modern CSS [2]. There was a thread on HN where some participants complained about "all these newfangled CSS features". Several didn't see the need to learn CSS Grid, even though it's been available for nearly 10 years. (Aside: I really disliked the floats/tables-for-layouts era, with the requisite IE hacks.)

There are lots of developers who don't see a need to use features they weren't using in the late '90s or early 2000s. For a lot of them, they'd rather use the devil they know.

There’s a huge gap between web developers who speak at web conferences, appear on CSS-themed podcasts, and who are members of standards bodies vs the 9-5 developer that works for some insurance company or school, who's not a CSS enthusiast or hobbyist. Using ITCSS would be awesome them.

Finally, there's nothing unreliable or non-native about ITCSS; it's just CSS where the layers are in specificity order. It doesn't get any more native than that.

[1]: https://almanac.httparchive.org/en/2022/css

[2]: https://modern-css.com

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

#415

Post by alwillis » Mon, May 18, 2026, 8:19 PM UTC

yawaramin wrote: post #323

christophilus wrote: post #259

Earlier quoted context omitted.

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

> With CSS names are global. Not necessarily. Nested selectors make it pretty easy to apply styles in a modularized way. See https://rstacruz.github.io/rscss/

> With CSS names are global.

You can limit selectors (not custom properties) to a subtree by using @scope.

On the horizon is @function [1] where custom properties can be local to the function.

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...

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

#416

Post by alwillis » Mon, May 18, 2026, 8:24 PM UTC

jakelazaroff wrote: post #320

the_other wrote: post #267

Earlier quoted context omitted.

> With CSS names are global. In your "programmatic" code (your JS/TS, python, C++, whatever..) your classes are global. Even if the language supports flexible namespaces, or module scoping, you still have to take great care naming because reusing a name will cause you confusion. Giving two things the same name makes them harder to import, and risks clashes and bugs. No-one complains about this. This is just how you c…

In "programmatic" code, declaring two classes with the same name in the same namespace is generally either some sort of syntax error or one will "shadow" the other; it doesn't just silently merge the behavior of both classes .

[flagged]

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

#417

Post by alwillis » Mon, May 18, 2026, 8:34 PM UTC

alwillis wrote: post #135

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…

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

This is an excellent resource for using CSS as it was designed to work. It'll give you a different perspective on using CSS [1].

[1]: https://every-layout.dev

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

#418

Post by alwillis » Mon, May 18, 2026, 9:33 PM UTC

infamia wrote: post #198

alwillis wrote: post #155

Earlier quoted context omitted.

It's unfortunate Inverted Triangle CSS (ITCSS) isn't more popular. Instead of resisting the cascade, it embraces it and makes it work for the developer. The summary: write your CSS in specificity order [1]: /scss/ ├── 1-settings. ITCSS basically does away with specificity wars in a CSS codebase. Usually the only place !important is the utility layer. [1]: https://matthiasott.com/notes/how-i-structure-my-css

This is brilliant, I was not aware of ITCSS. Thank you for sharing! The link you shared fits my brain a lot better than pure BEM/CUBE, which works but always felt weird and uncertain to my style. Sprinkling a bit of BEM on top of ITCSS feels just right. shame.scss is the snarky cherry on top. Thanks again, you have enlightened at least on person today! :)

In hindsight, ITCSS is so obvious. Makes you wonder why so many people think CSS is difficult.

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

#419

Post by fluffybucktsnek » Mon, May 18, 2026, 10:06 PM UTC

TonyAlicea10 wrote: post #140

vehemenz wrote: post #15

Earlier quoted context omitted.

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.

TBF, Tailwind is more about optimizing CSS sizes via the utility classes approach IIRC.

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

#420

Post by fluffybucktsnek » Mon, May 18, 2026, 10:08 PM UTC

extra88 wrote: post #401

stefan_lec wrote: post #314

Earlier quoted context omitted.

Details/summary had quirky/inconsistent handling by screen readers for quite a while after it reached full browser adoption, unfortunately. Not even sure if they’ve fixed it here in 2026, honestly. https://www.scottohara.me/blog/2022/09/12/details-summary.ht... While it’s good to use well-implemented semantic elements when possible, there are still plenty of places where either the built-in browser behavior isn’t act…

I think popover and invoker commands with polyfills are already the way to go. The polyfills are small (and if you only want to use the "show-modal" invoker, it's like 10 lines to feature detect and polyfills just that). Many good uses of popover really needs anchor positioning. There's a polyfill for that as well but it's not small.

It should polyfills are basically a no-go for no-JS sites.