Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

211–220 of 435 posts

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

#211
post #131

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

> 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

Tailwind classes are literally vanilla CSS classes. You can copy-paste their definitions directly

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

#212
post #70

Earlier quoted context omitted.

The common arguments against Tailwind usually derive from total ignorance of working with CSS on large scale projects with many team members. And when this is pointed out you’ll usually get replies that just hand wave it away as not a problem, as if things like BEM were invented for no reason.

Yeah, that's a straw-man. I've worked on large-scale projects with many team members, and it's perfectly possible to use CSS as it was designed. But sure, like most tools, it starts with understanding how it works.

“That’s a straw man”, he says, as he hand waves it away as if it were not a problem

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

#213
post #162

I just want to point out that you can use Tailwind inside your CSS with the `@apply` directive (not to be confused with the since abandoned CSS `@apply` rule). You write your CSS and mix in Tailwind instructions where it makes sense. Example: @import 'tailwindcss'; p { @apply text-justify; @apply bg-slate-300 dark:bg-slate-800; /* Second rule just for colors */ display: block; /* regular CSS */ } I used to be a big T…

> putting all those utility classes as inline styling into my HTML is a crime against nature. It’s really not when working with components instead of pages, and when working with variables properly

Even with components I prefer what Astro is doing: the component can have a `` tag in which I can add my own CSS. When building the website Astro will know how to transform the CSS so it only applies to that component. This way markup and presentation remain separate even if they are within the same source file.

https://docs.astro.build/en/guides/styling/

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

#214

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…

Your comment is getting downvotes, not necessarily because you are wrong, but 1) CSS is indeed hard, complex and often confusing, which is partly why Tailwind exists in the first place 2) your comment points out some inconvenient facts, and people don't like that

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

#215

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…

Isn't the same true of those who use a library that wraps SQL?

I think there is a wide spectrum of "wrapping SQL", and very likely not because someone doesn't know SQL well. Depending on the use case, it can be just the right solution or overkill.

Tailwind, on the other hand, attempts to address a different set of problems, but I am not getting into that here -- other comments have summarized it well.

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

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

Your framing assumes incompetence across the board which is unlikely to be true for a framework of its popularity. Consider instead competent people are working on projects with different needs and they’ve recognized there are trade offs to both approaches and still decided Tailwind makes sense in their situation.

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

#217

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…

That’s the value of tailwind. You can just skip learning CSS and still get a good result. The benefit to learning it is marginal.

> You can just skip learning CSS

It works until doesn't, and you'll have to figure out what's going on with your code.

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

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

To be honest, CSS had the cascade but also had horrible tools for actually managing the cascade for a long time.

If CSS had nesting, variables, media queries, the other nice selector queries like :has, and modules out of the gate, we likely would have not needed much of the tooling like tailwind that eventually got built to manage it all with less boilerplate. We built the tools because even when these features rolled out they came in fits and starts so you couldn’t adopt it without polyfills and whatnot.

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

#219
post #73
post #34

Earlier quoted context omitted.

Why did Svelte affect your stance towards Tailwind?

Presumably because you just put the styles in the component.

Yes and Svelte automatically namespaces them, so there's no collisions.
Post reply on HN