Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

191–200 of 435 posts

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

#191

Earlier quoted context omitted.

You're not wrong, and I mostly agree with you. I die inside when I see the div soup that a lot of sites have become. However, I think there is value in being able to have the important parts of CSS merged into the HTML a bit. Where that line is, is certainly up for debate (and I don't have the answer), but I've found a lot of my tailwind sites are more readable to me than my pre-tailwind sites, often because I don't…

The "open a different file" reasoning piece is a common pro-Tailwind statement and I do see the upsides. I think that upside became more prevalent in the reusable components era, whereas previously CSS was targeting an entire HTML file (and thus the reasoning was more like SQL query than "this one element's styling"). With LLMs I think this upside is much smaller now though.

> With LLMs I think this upside is much smaller now though.

With LLMs Tailwind wins. Because it's a very restricted set of classes. With regular "separation of concerns" CSS, LLMs will happily just pile on more and more and more CSS because they can't really analyze the code that's already there, and will miss and re-create huge chunks of CSS. Or write increasingly hyper-specific CSS to fix reported issues.

Anecdotally: in a side project I now have 10k lines of "pure" CSS generated by LLMs on top of Tailwind. The web part of the app is ~20k lines (not all of them are rendering anything on screen). No idea how to fix it :)

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

#192

It bothers me that SMACSS is from 2011 and was completely ignored. That was the sane way to write CSS. Been doing that for more than 10 years and never had issues redesigning large applications. https://smacss.com/

That site is a portal back to 2011, wow. Thanks for sharing.

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

#193
post #159
post #120

Earlier quoted context omitted.

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

> And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely. The client still has to decompress it and waste processing power parsing all the repeated text.

Premature optimisation doesn’t even fully express how absolutely ridiculously futile it is to try and make your website faster by having fewer CSS selectors.

It’s like my grandparents worrying about immediately switching off their LED ceiling lamps when they leave a room - meant well, but utterly meaningless.

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

#194

Earlier quoted context omitted.

It's not just blind people, but also people with reduced eyesight. As I'm getting older, I really appreciate good contrast and the possibility to zoom in without breaking the layout.

And how does tailwind or the structure of the underlying html of the page change or affect that?

If Tailwind lends itself to using pixels instead of relative units for things that should be relative (like font-size, line-height, etc.), that's a problem. For those users, the HTML elements matter less unless they're savvy users who have custom user stylesheets to selectively adjust the appearance of content instead of changing everything on the page by zooming (e.g. make links, buttons, paragraphs, list items bigger and/or a different font or weight).

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

#196
post #164

Earlier quoted context omitted.

> It is confusing and takes time to get used to I don’t believe Tailwind is inherently worse than pure CSS. If Tailwind had existed from day 1 on the web and you had learned it first you probably wouldn’t say this. In fact, if Tailwind had existed first somehow, and someone came up with CSS as we know it as a new revolutionary library, I’m not sure it would have succeeded.

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

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

#197

Earlier quoted context omitted.

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

> 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. That seems like a false dichotomy. I'm a huge fan of locality (both in software engineering and in physis) but you can also "localize" your styles by scoping them appropriately. (Modern frontend frameworks typically do that automatically for you at the comp…

Yes, you could build your own framework to localize your styles. Or you could just use Tailwind.

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

#198

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

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! :)

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

#199

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

Which semantic element(s) would you use to build the example from the Tailwind website?
Post reply on HN