Moving away from Tailwind, and learning to structure my CSS

Posted by Either_Collection349@reddit | programming | View on Reddit | 25 comments

[-]

romulof@reddit

Call me old fashioned, but I never understood why people were so desperate to move styling into HTML or JS. It’s way harder to debug.

For me the peak is CSS modules with a bit of preprocessing (sass and/or postcss). In dev builds you get the almost the same as the original class names and prod builds get obfuscated.

[-]

Debugging pure css is hard because you have to remember or look up what class names do and because css has varying levels of specificity and cascading rules. Utility class frameworks aim to reduce both by (1) standardizing so that you don’t have to learn project specific naming conventions or memorize/look up css when reading the markup and (2) enforcing single-class-name-only rules (no ids, no nested rules, no variance in specificity)

[-]

natural_sword@reddit

Browser devtools make debugging CSS pretty easy. Writing it consistently is the problem. As with most concepts, if you over-utilize the cascade, it will bite you.

I've settled on a few global classes and then component classes. I find doing bespoke CSS is better to satisfy random design requirements.

[-]

ur_frnd_the_footnote@reddit

Totally. I also do enjoy the elegance of bespoke css. But my point (and I think the industry trend) is really about joining and contributing to projects with other developers and history and teammate churn (and hopping between diverse projects).

[-]

pm_plz_im_lonely@reddit

I think it's fast results + components allow encapsulating and limiting the size of the clusterfuck.

[-]

romulof@reddit

That’s what CSS modules is for. Zero runtime overhead.

[-]

ragemonkey@reddit

If you read the tailwind author’s blog he explains that he got tired of giving names to everything or to repeat the DOM structure as selectors somewhere else.

I had a negative reaction to tailwind at first, but after using it for a few years, I really like it. In a world where DOM structure can be turned into reusable components, there’s really not much to gain from separating style and structure. In fact, sharing styles becomes more of an anti-pattern to be avoided.

[-]

WanderingStoner@reddit

one thing to note is that if you let ai just choose what it wants to do, it will likely choose tailwind. I'm not saying that's a good reason to use it, but it's one reason that it ends up being implemented.

[-]

Agloe_Dreams@reddit

The primary reason is that it is faster for AI to write everything in small bits of contained context (a html block in tailwind stands alone) than to have to repeatedly cross reference a second file. Having shared classes and wording about cascading is a context window nightmare.

[-]

romulof@reddit

Training data will lead it there. Lots of tw projects.

Don’t ask it to write in React and it will probably go for jquery.

[-]

Agloe_Dreams@reddit

Because the styling of a page was always in two places already. HTML defines structure and style, CSS defines structure and style. Putting them together gives a single source of truth in an app.

You also solve the SPA cross contamination issue of classes in page A impacting elements in page b.

[-]

MaybeADragon@reddit

Its the ability to have everything relevant to an element on a page be grouped together. That's my opinion, I only write frontend stuff for a hobby I'm mostly a backend and application fella so my word is by no means gospel.

[-]

ManySugar5156@reddit

same, colocation is the only part i actually miss. the rest gets messy fast.

[-]

superrugdr@reddit

Pretty much this .

while I like one class per components when you have 20 devs working together on the same stuff. It get messy quick.

Tailwind help provide structure while also giving you a pretty functional base design system.

It's not my favorite approach but the benefit out weight the negative

[-]

HiPhish@reddit

Call me old fashioned, but I never understood why people were so desperate to move styling into HTML or JS.

My guess is that a lot of those people don't understand CSS and using inline styles allows them to get by without understanding the cascade. If you use a framework like React all the markup, logic and styling are then in one place.

[-]

JoJoJet-@reddit

Yeah, it's this. CSS is global. React makes things local. Tailwind is mostly local and pairs pretty well with react. I still prefer CSS, especially for complex styles. But tailwind can be easier to reason about in react.

[-]

GenazaNL@reddit

Same here and soon we might not even need pre-processors anymore. CSS getting a bunch of stuff natively

[-]

Select-Reporter5066@reddit

The funny bit is Tailwind being the training wheels that teach you enough CSS to eventually remove Tailwind. Frameworks do love becoming the tutorial boss.

[-]

programming-ModTeam@reddit

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.

[-]

HiPhish@reddit

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 Tailwind hater because putting all those utility classes as inline styling into my HTML is a crime against nature. But this way I get the best of both worlds. Tailwind is really nice as higher-level building blocks and saves me from writing a bunch of media queries.

[-]

mtutty@reddit

Well, that didn't last long.

[-]

ReallySuperName@reddit

I've migrated away from Tailwind but probably not for the reason most would; I wanted more control and to have a more strongly typed experience.

So I went with https://vanilla-extract.style/ which is similar at first glance to Styled Components, except it's all done at build time, requires zero JS in the browser, and can be used with any frontend framework.

I find it immensely capable for building a constrained-on-purpose design system/component library that prevents other teams fucking it up and adding some one-off spaghetti bullshit. If there are gaps in the designs, it forces them to properly get everyone in the loop and add new component variants properly.

If you've ever tried to build a design system with Tailwind and TypeScript you know exactly what I'm talking about when I say that Tailwind has an upper bound where you end up needing to have giant maps of component variant props to Tailwind classes and it turning into a soup.

Very few people are actually interested in writing design systems/component libraries well or even at all, so I think my suggestions here will simply be misunderstood or cause a lot of drama in the replies.

[-]