Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

361–370 of 435 posts

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

#361
post #235

Earlier quoted context omitted.

I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.

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.

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

#362

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…

"beyond a junior level" -- I doubt this will change your mind, but this post is from the author of Tachyons, a "pre-Tailwinds" competitor that didn't get the same traction:

https://mrmrs.cc/writing/scalable-css/

And the tldr is that he downloaded and read the CSS for several major websites at the time (post is from 2016) and they were all hodge-podge of terribleness.

Maybe all the devs writing that CSS were junior, but imo it's more than CSS just doesn't have the abstractions to match the level of OCD/bespokeness that designers spec into every Figma -- move this box by _this_ much / _that_ much / etc.

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

#363
It seems to me there are always two camps when it comes to CSS vs. Tailwind. The one claims that CSS was the right solution all along and it should just be learned and adopted. Then there are others that say that Tailwind makes CSS more approachable and learning CSS never had priority.

I'd like to think that LLMs help with the first approach, I'm certainly now a little more curious to try plain CSS again.

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

#364
post #54

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

i am no pro-- just a lurker wanting to learn -- and comments like danaw's are the reason my time on HN is not wasted. Thank you.

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

#366

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 .

TypeScript interfaces just merge. You can aet any property name you like on a plain JS object, at any time.

The CSS version is a risk, for sure. The dev tools in all the main browsers will tell you where the extension happens and show yiu the order the complecting rules are applied, so it’s fairly easy to debug. Bugs/misbehaving code is usually a problem of structure. In other languages, we take on the need to apply structure; just do the same with CSS.

The mechanism that allows this merging behavior is the means by which intentional reuse is composed. It allows yiu to set general and specific rules sets. This seems conceptually similar to OO classes and subclasses, to me.

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

#367
post #351

Earlier quoted context omitted.

CSS modules solve all of these problems.

They don't, really. The only thing they solve is side effects, but you'll still want shared conventions across your modules.

If you're using components, it's the same as Tailwind, just put your CSS module files next to the component, or use compile time CSS in TS frameworks like PandaCSS to have them in the code itself. For shared conventions that is the purview of the design system and you'd have CSS tokens for various colors etc. Anything you can do in Tailwind you can of course do in CSS modules because it's CSS at the end of the day.

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

#368
post #123

Earlier quoted context omitted.

You aren't wrong, but the _overwhelming_ majority of "full stack" devs I've worked with only know CSS at the most basic level and have little interest in learning it in depth. I myself have been programming for more than 20 years, doing web dev for almost 15, and I can't find the motivation to learn it well. There are too many technical skills to keep up with and CSS is pretty low down on my priority list. I would pr…

This is where I'm at. React makes sense to me in ways that plain CSS doesn't. I've learned about 15 programming languages by now, each time out of necessity, but CSS isn't one of them.

Josh Comeau had a good course on CSS, I've used that to learn CSS from scratch.

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

#369

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…

I'm a big hater of Tailwind but also know that most CSS out there is an absolutely clusterf of outdated rules and !important wars. There's no winning when some dude jumps into the codebase and fixes a bug by adding margin-right to "p"

CSS linters never really picked up steam and even with them, what's lintable is quite limited.

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

#370
post #54

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

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.

Post reply on HN