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.

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.

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.

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.

Don’t know about tailwind but I used styled-components and not going back to vanilla css. CSS seems to be designed to be used with HTML, which did make sense back when it was created. Modern web is 99% JS and components composition which does not work well with Vanilla CSS in terms of class name uniqueness, specificity. Also it easy to dumb shit with CSS, like, I worked in the project where we had a lot of legacy global CSS. We had like dozen CSS styles which were adding margin to , and so on. I mean no classes, just globally. I’ve been forced to add ‘all: unset’ to basically all my new components just to avoid changing global styles and breaking something else. Do not recommend.

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.

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