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.

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.

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

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

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.

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.

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.

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

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

It’s a nicer syntax for inline styles.

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

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.

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