Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

261–270 of 435 posts

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

#261

One approach I've been really starting to enjoy is to use use Tailwind alongside scoped styles (in Svelte and Vue). This keeps template pollution minimal while still allowing for the conveniences Tailwind brings: + {{ count }} @reference "tailwindcss" .counter-component { @apply flex items-center gap-2; button { @apply bg-gray-800 text-white; } .count { @apply italic text-teal-500; &[data-is-even="true"] { @apply tex…

yeah, likewise, I locked in on this very early on even though it goes against what the tailwind creators recommend. But I've never regretted this approach and it works well.

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

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

[flagged]

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

#263
post #245

Earlier quoted context omitted.

I think this assertion is where most of the conflict comes from. There is a fair amount of people that disagree with the premise that it should be separated in that way (Including me). I personally like this essay by the author of htmx on the topic https://htmx.org/essays/locality-of-behaviour/ Also just better composition imo. Practically I think this means components of scoped css, html, js. People never seem to ha…

I separate those too. Queries get their own file. Sometimes their own framework.

Sorry maybe that wasn’t the best example. It’s not really about separation of files. But how they connect.

In sql your code may be in a seperate file but your app code is still clearly calling the sql. The inlining vs not inlining is just abstraction. You could use a function, or a separate file or not, a different language or not.

But there is a clear single call chain at the points where that behaviour is being applied and a single definition.

With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply.

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

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

> inline CSS can't be cached

Can you elaborate what the problem is? What is it you want to cache?

> and it creates a lot of noise when using dev tools for debugging.

I don’t think so. The element styles have an own section (assuming you debug the applied styles)

> It actually increases cognitive load because you have to account for CSS in two different locations.

Same applies to no tailwind. You need to account for the html (is parent block / inline / …) anyway.

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

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

> 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 when you're building complex systems tailwind allows us to reason more clearly about these often very complex components

> inline CSS can't be cached

this shows your lack of understanding. first off, it's not inline css, they're classes and thus you only ever define "flex" in one place vs many many places in non-utility css approaches. in fact, sorted html classes are compressible over the wire so you're doubly wrong.

> because they never learned it properly condescending

> it lets you use CSS while not requiring an understanding of how CSS works, beyond its most basic concepts also condescending and just such a boring, over used argument i always hear from haters of tailwind maybe try and counter my arguments without the attitude? maybe understand seasoned veterans of css might have their reasons to choose it?

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

#266

Earlier quoted context omitted.

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.

[flagged]

have you ever built a complex web app? with you're snarky reply my assumption is no

any experienced developer without a condescending attitude can recognize all types of programming require skill and nuance to build good software, no matter the target

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

#267

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…

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.

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 code in all those other languages.

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

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

If a tool’s design makes it easy to cut myself, the response is not “people have been cutting themselves for years”. There is such a thing as the ergonomics of the tool. Yes div soup has been around a long time. But also yes, Tailwind makes the wrong approach the easy one. It’s ergonomics encourage adding div elements to support styles. It’s the core design loop. You’re conflating “forces to” and “ergonomically encou…

i just don't agree tailwind makes it any more easy to make div soup than any other approach. if you don't care or know how to build proper markup no style approach is going to save (or hinder) you

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

#269
post #254
post #147

Earlier quoted context omitted.

Global state is bad because it’s mutable. Global styles are not mutable.

Global styling done messily can override local styling. It’s the hardest kind of problem to reason about! I do think that stuff like bootstrap is generally good at avoiding this but it only takes a handful of improperly scoped high level CSS rules to cause awkward hard-to-fix pain much later on.

Learn how cascading works, then learn how to use the web inspector. I'm using Firefox and the style panel list the the selectors used in order of priority. And you can filter by properties to see which one is overriding everything else (i.e the only one not crossed out).
Post reply on HN