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.

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.

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.

Working on hobby or shorter lived projects makes all your points agreeable. My work is generally on enterprise SaaS software with vast lifecycle and my thinking is

separate css files

module.css with imported classes: my go to outside of tailwind

These are the same thing, unless it’s not configured correctly.

inline styles

Only makes sense for something computed. Like a color computed based on a user selection. Otherwise it should be a class

scss

On a well-maintained project SCSS should be second nature. Something like a Vue single-file component project with scss will certainly not add to the bloat. You’d just have extra lines of vanilla css to scope classes and children selection/scoping that scss does with better syntax, in addition to scss functions and the like. Note that CSS is improving to do the work that SCSS has previously done, just as JS is improving to do the work natively that frameworks, libraries, and toolkits have previously done.

bootstrap

Yeah bootstrap, like jQuery, had it’s time. It’s largely been replaced by native tooling that shouldn’t require external libraries. There’s plenty of CSS libraries that are purely for theming, which is mostly what people used bootstrap for. (Smart defaults, basic component and typography themes, etc).

To me tailwind makes sense for setting up projects quickly, but gets out of hand when it comes to customization on a larger scale. You eventually end up with overrides to tailwind’s default styles that become hard to manage, outside of the scope of their theming implementation, and then ironically you’re usually just using CSS variables which is back to the core toolkit.

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

fun fact: This isn’t any one specific CSS framework’s doing but rather part of how JS UI libraries handle scoped CSS. When you have for example two components that have similar CSS, like one component sets button to color green, another component sets button to blue, then the compiler does this kinda thing because “real” CSS doesn’t support scoping.

So in the above example you’d get button class abcd and button class bcde.

I’m honestly not sure, but I’m fairly certain it’s intentional obfuscation done for the production build. Why they think it’s so important to hide class names, I’ll never know.

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.

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

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.

It’s a nicer syntax for inline styles.

If you want to use inline styles everywhere, it’s great.

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

I guess some people write code, and some people also read and maintain it.

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.

It shocks me to see how many programmers think such framework decisions are one-size-fits-all and jump to conclusion that such framework adoption decisions are is due to lack of skillset and experience.

There are many factors at play. You have time to build and maintain your own utility framework, please go ahead.

Two years ago, I led a team which developed a web app that generated 600 million impressions per year. We used Tailwind because we were a small team and I’d rather have my developers work on high value tasks and not maintain a style framework.

If you are an aspiring developer, know this: There are always trade-offs. Not writing pure CSS does not make you a bad developer. Not knowing system design does.

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

And they hated him because he was right.