I’ve never quite understood how adding all these HTML classes to a page is supposed to be clean. Just do a decent job of organizing your code and it’s honestly not that hard to keep from breaking styles unexpectedly. This is the part you tell me “well that only works for small projects”. Not really, it works when styles are managed carefully. I’ve worked on fairly large sites with what modern standards would call “bad” css practices and it was fine, we just had an understanding that some devs were frontend (I was lead for a couple years at this particular company I’m thinking of) and some were backend. The backend people botched styles every time so we forbade them eventually. I think that contextless type of “help” is where people get the idea that you have to have a css setup that prevents people from breaking anything unexpectedly. CSS just gets no respect. You wouldn’t let a frontend guy go changing your core backend code so why is the reverse ok?

I like css modules too but I totally disagree that css is irreparably broken and needs some system that discourages the cascade of styles in all cases.

Honestly, I’m still very much in the “classes define what a tag represents, CSS defines how it looks” camp. While the old semantic web was never truly feasible, assigning semantic meaning to a page’s structure very much is. A well-designed layout won’t create too much trouble and allows for fairly easy consistency without constant repetition.

Inline styles are essentially tag soup. They work like a print designer thinks: This element has a margin on the right. Why does it have that margin? Who cares, I just want a margin here. That’s acceptable if all you build are one-off pages but requires manual bookkeeping for sitewide consistency. It also bloats pages and while I’m aware that modern web design assumes unmetered connections with infinite bandwidth and mobile devices with infinitely big batteries, I’m oldschool enough to consider it rude to waste the user’s resources like that. I also consider it hard to maintain so I’d only use it for throwaway pages that never need to be maintained.

CSS frameworks are like inline styles but with the styles moved to classes and with some default styling provided. They’re not comically bad like inline styles but still not great. A class like gap-2 still carries no structural meaning, still doesn’t create a reusable component, and barely saves any bandwidth over inline CSS since it’s usually accompanied by several other classes. At least some frameworks can strip out unused framework code to help with the latter.

I don’t use SCSS much (most of its best functionality being covered by vanilla CSS these days) but it might actually be useful to bridge the gap between semantically useful CSS classes and prefabricated framework styles: Just fill your semantic classes entirely with @include statements. And even SCSS won’t be needed once native mixins are finished and reach mainstream adoption.

Note: All of this assumes static pages. JS-driven animations will usually need inline styles, of course.

Would be fine if it used a custom parameter for their tags. Using class names makes for bad accessibility.

except we generally use higher level abstractions now, like component based frameworks. If you’re writing raw html with tailwind and no library you’re doing it wrong and css is a better fit.

well written straight css ends up building it’s own tree of components. if you’re using react too you’re either only selecting a single component (inline styles but have to open two files) or writing good css (duplicating the component hierarchy in css).

tailwind is just the former but better since it encourages using a projectwide set of specific sizes/colors/breakpoints and small scope, the two actual problems with inline styles after organization and resuse, which react etc solves.

That’s a common misconception by people who never used it. The truth is you need to know CSS to use Tailwind. Just because it simplifies styling doesn’t mean it simplifies the underlying technology.

This is the correct answer. Pig-headed arrogance is why this cancer of a framework exists.

And they hated him because he was right.

People fear what seems foreign. Devs want css to be like a programming language and it’s not so they’re uncomfortable. Or at least this is my unvarnished opinion

It helps to avoid the specificity problem. You don’t have to manage a complicated class system, you just set styles directly on the elements. Yes this is pretty much what everyone agreed in the past was the worst thing to do but that was before things like CSS variables existed (which Tailwind uses excessively) that lets you control details like color and fonts from a single point. So you don’t have to go through every component to change the brand color.

At work we don’t use Tailwind often but in our React apps we mostly use Theme-UI which lets us write regular CSS on each element in a nice JSON format instead of the class name hell that is Tailwind. This is my preferred way.

I was very much against frameworks initially: tailwind, bootstrap etc. However, when I started really building sites & apps using components, I found tailwind made my life a lot easier, so I could easily see and change styling while writing code/html, and it would only affect that component.

Beforehand, I was trying to come up with names for CSS classes all the time, and then I’d change one thing, and fuck up styling on a diff page.

Tailwind sounds cooler than CSS, which, I presume, would be important when you’re applying at a startup.

It’s actually very useful. All these negative comments have the hallmarks of people who don’t generally use it. I can tell because the criticisms stem from a lack of familiarity, missing the point.

No, it is not that bad. It’s actually very nice.

It affords a lot of consistency, is relatively easy to understand (once you’re familiar with the convention), and theming allows you to modify all the colors and sizing in one file rather than modifying a lot of CSS

I think the worst that can be said about it is that it is unnecessary, but I cannot see a true downside to using it besides personal preference. It gets the job done efficiently and correctly and that’s what’s important at the end of the day

I’ve not used it in anger but the principle just seems like inline-styles with extra steps. However I’ve also had to change something in a large project that had a lot of dedicated classes with specific and shared styles and trying to sort that out without breaking stuff was a massive pain.

At first it seems nice…I played with it for a few hours in an established project and didn’t mind. But the I thought about using it from scratch and I’m just baffled anyone does. It’s like if CSS was slightly more abbreviated but you couldn’t use classes so every style has to be specified on every component.

yea it’s redundant as hell if not combined with UI libraries that extend it like shadcn / daisyui