have any of you switched from using Tailwind to regular CSS? was there anything that helped you make the switch? was it tools like sass? a really good guide to structuring your css? I want to know!

I ask because I'm getting a little tired of Tailwind but I still have a hard time with normal CSS

(please only reply if you yourself have switched your allegiances from Tailwind to vanilla CSS)

@b0rk I’ve always avoided Tailwind, so I don’t have a direct answer to your question, but I am curious what you have a hard time with in CSS (if you can even articulate it — I know how that goes)?

@keithjgrant i guess i think of css as maybe 4 things:

1. design (which isn't really CSS at all)
2. the rules of CSS (like how flexbox works, stacking contexts etc)
3. debugging skills
4. structuring your CSS in a maintainable way

#1, #2, and #3 feel pretty achievable to me but #4 feels like a bit of a mystery

it's not a question I like to ask directly because there's way too much advice out there and I'd really like to hear from someone who (like me) finds tailwind's structure appealing

@b0rk Josh W Comeau’s CSS course is excellent, although its geared to using CSS in JS apps. I think it covers 2, 3 and 4 really well.

@jamesking yea it seems good but realistically I have never managed to do more than 5% of a course in my life and I don't think that's going to change sadly

@b0rk I used tailwind for several months working for a client that preferred it, and got the hang of it pretty well. I wouldn't describe myself as a convert, but I understood it.

I spent some time with sass and it's pretty good, but to that end I've found that just indenting my css to match the selector hierarchy provides most of the same benefits I was getting out of sass.

the mental framework that helps most for me is focusing on the cascade. (1/3)

@b0rk I've seen a lot of people say that structure and style should be separate. while I get where they're coming from, I'd argue the nature of cascading directly disagrees with that perspective.

my approach is focusing on what should be true from the top down, naturally narrowing the scope through the cascade. if it isn't true for everything (or the vast majority of things) _within_ a container, it doesn't belong in the container's style. move that responsibility down the cascade. (2/3)

@b0rk this ties together structure and style, sure, but I often find that my understanding of a design's structure changes as I'm working on implementing its style, and a top-down approach forces me to think about everything _within its context_ rather than as individual truths.

I think that's the trap of frameworks like Tailwind; they guide focus to the individual pieces rather than their context. imo that focus belongs in the polishing phase, not from the start. (3/3)

@sampj hmm do you have an example? i can't tell if you're saying that you prefer to write selectors that are more specific or less specific (or something else entirely?)

@b0rk sure!

so imagine you're staring at a blank page and have a napkin with a rough structure sketched out next to you. the framework (ex, Tailwind) approach, at least in my experience, encourages deciding on the innards before its parents, and that results in a mess of repeated code and style overrides.

instead of focusing on the innards, think about what's true for everything and declare that in the body. then think about what's true for everything inside the top-most element. and so on.

@sampj i appreciate that thanks! I honestly cannot imagine working that way but maybe one day I will understand that way of thinking :)

@b0rk I would love to know this as well, as a more backend dev who doesn’t know Tailwind but would like to make a not-terrible web app…

@b0rk Have been thinking about if I should reply...

I liked writing html to describe the content (em instead of I), css Zen garden, etc.

I stopped doing css/webdev because I did not keep up with all the modern stuff and only learned the basics back then. Doing everything "by hand" always lead to ugly results and/or a mess and lots of trial/error. (1/2)

With tailwind everything was easy and I only had to pick things and the result looked great. If I'd do some Web stuff again I'd try to create meta classes that point to tailwind stuff but describe the content. So the best of both I guess.

Why do you dislike tailwind? (2/2)

@fink i really love tailwind! I think the reason I'm wanting to move closer to vanilla css is that I end up using some regular CSS anyway (for things that tailwind doesn't support) and I don't love the build step that tailwind adds. it feels like it would be nicer to have everything in one place.

@b0rk I'm in the same boat. I was a long time plain CSS user, then I got into Tailwind but I am looking again at plain CSS. TW is great for prototyping or slapping something together, but once you maintain a project long term, it gets unwieldy.

I haven't switched back yet (I'm scared of ending up something completely different but equally unwieldy), but here are a couple of links I spotted:

https://www.spicyweb.dev/css-nouveau/1-vanilla-has-never-tasted-so-hot/

https://every-layout.dev

Please share with us your journey back to plain CSS!

@teleclimber I've been thinking of sticking with Tailwind for prototyping (it's so good for that!!) but then migrating the project to vanilla once the prototyping stage is over