[ComiCSS] Benefits of Tailwind

Tailwind is like going back to in-line styles. If you add font tags you are back in the 2000’s

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 cannot tell if you're saying tailwind is taking away from useful abstractions or adding to them. I think it's taking away from them. A whole bunch of class names in the page is opposite to what we were taught and there was a good reason for the lesson: content and presentation should be defined separately. This lends flexibility, readability and accessibility. Tailwind doesn't help with anything but preventing a breakage in another component/page. To me the reason to value this trade off is that you don't want devs to "have to care about css" which is a bad sign to begin with. It says "we think the way the web is built is bullshit, so let's just try to work around that with the latest attempt to make it better". The web is not bullshit. CSS is beautiful. Embrace the challenge. (Sorry I'm only halfway directing this rant at you)

Genuine question : what's wrong with modern vanilla CSS3 ?

Maybe it's because I've used css2 I don't see the point of css frameworks.

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.
- Honestly love tailwind. Once you get used to all the names/abbreviations and how they work with sizes and states etc. it's much easier to see what's happening when eyeballing code.
  Makes reviewing and bug fixing easier too.
  I get that early on it feels annoying. I recall disliking it the first time I learnt it, but then when I went back to regular css and classes I really missed it.
- Now it is remembering tags for property instead.
- Yep, a component is a good abstraction level, no point in making life difficult by creating and coming up with names for smaller parts.
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.
- This is very informative. I avoided Tailwind for the reason you mentioned, but look closer now that I know the difference.
- Why Tailwind if you have CSS variables?
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
- For me it's less about fear and more about having a limited budget of time and effort to spend on learning things, so CSS and front end generally gets deprioritized. But that's cuz I'm a back end kinda dev in my soul, lol.
  I've seen the good points you've made elsewhere in this thread - I would indeed react very poorly to willy-nilly back end changes and I think you're right that people don't give CSS and visual styling the same degree of professional respect when making changes. And that sucks.
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
<label/>
,
<p>
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.
- I tend to build stuff with html css and php only ( all vanilla) and avoid non trivial js like the plague. I can see your point but for me replacing HTML with js is just wastefull, you leave performance and built in accessibility on the table for a slightly more convenient experience that don't work for me.
Tailwind sounds cooler than CSS, which, I presume, would be important when you're applying at a startup.

Ngl I love tailwind, I've been through so many different css paradigms

separate css files: why did we ever do this, if you've ever used kendo's css stuff you'll understand how unfathomable hundreds of thousands of lines of css with complex rules is. Identifying all the things that affect a single component is the work of dozens of minutes at minimum, sometimes hours, you have to understand every nook and cranny of the css spec.
inline styles: fine, but verbose and requires object spreading, harder to compose, theming is tough and requires discipline to be consistent in your theme conventions, almost impossible to also theme imported library components
module.css with imported classes: my go to outside of tailwind
scss: I actually really like scss but it exacerbates the complexity and mystery of css, great for small projects but terrible as projects bloat
bootstrap: basically just worse tailwind, providing only components and colors

That's all I can think of right now, but tailwind is my preferred way to style a new project, I love how easy theming and style consistency is

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.
Would be fine if it used a custom parameter for their tags. Using class names makes for bad accessibility.
- How are class names relevant for accessibility?
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.

Which CSS framework is it that puts this shit everywhere?

That one can die in a fire.

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.
- How *some JS UI libraries handle scoped CSS. Vue for example uses data- attributes instead.
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.
- To fight ad blockers
- It is not intentional. The tooling needs to generate a short unique id to prevent css name clashing.
  During development 2 developers can write the same css class name in two seperate places:
  developer A: .container { padding: 8px } at dashboard
  developer B: .container { padding: 32px } at sidebar
  Without this tooling developer need to find ways to prevent name clashing:
  .dashboard__container
  .sidebar__container
  and they need to do this for every class name.
  with this tool, developer don't have to worry about this ever, continue using .container and it get generated into:
  .aP2be7
  .7aFrJp

I've used raw CSS for the last 2 years at work and it's not like it's magically better or my productivity is higher or that it is simpler to read and understand.

Use the tool that works for you, tailwind is fine.

As one who creates usercss to fit pages to my needs, Tailwind is second worst.

Tailwind is for people that don't know how to use CSS properly. There, I said 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.
- you need to know css to use tailwind because it’s basically style= on everything: it’s css with extra steps
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.

In my personal projects, I don’t use anything. I wrote a set of utilities and functions in SCSS years ago that let me easily create reusable variables and classes that already do what TW does, but with less bloat and overhead. I get project-specific spacing, colors, font classes, everything.

I also highly recommend picking up Andy Bell’s Complete CSS course.

I wonder if any colorblind people completely didn't understand this meme

Having never used it before, is it that bad?

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.
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.
- A lot of ui frameworks are based on tailwind and allow you to customize the components with more tailwind. It's really a win because:
  it's not "just inline classes", it's a design system (spacing, colors, breakpoints etc are well structured and not random)
  it is way less verbose than vanilla css and easier to remember
- You can still use classes if you want to...
- instead of using classes you just use whatever your ui library provides for reuse. stick a classname string in a variable and you have a class. use a component and it just contains all its styles.
  unless you mean that if you look in the inspector you see a mess of classnames. I don't have a solution there
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.
- It's much more than just inline styles. It's also design constants (e.g. color palettes, sizing etc.) and utilities (e.g. ring).

They said that You either hate or love tailwind, and when I first used tailwind I assumed it was just a joke, 'why would they hate this? It's simple to use, remember, build, and it even removes unnecessary CSS that I forget to do...'

Apparently it isn't as simple as that.

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

A very colorblind chart

Seems like a lot of supportive commenters didn't try CSS-IN-JS like @emotion/styled, stitches, styled-components. Where are you guys? Why learning alternative names for CSS rules considered to be better, than just using those good ol' "let you do everything what you want"s.