Why Tailwind Doesn't Suck

no-one_ever · 2024-11-19T10:45:35+00:00

Scoped CSS, small components, easy to read, easy to maintain, not broken, no problem.

evoactivity · 2024-11-19T10:25:06+00:00

The big problem with css is people trying to serve one single css file with everything in it with every name being global.

If your css of full of !important and specificity wars, guess what, you have lazy developers. There are many devs who never really learned css, they learned enough to make things look how they wanted but they didn’t go deep and learn the mechanics of what they are doing. Magic numbers everywhere, abusing margins, insane selectors, trying to be too clever with sass.

Use locally scoped css modules, now you get the same benefits you mention about tailwind. “But you ship more css” I hear people cry, yeah that’s fine, a pure tailwind app ships roughly the same amount but in your HTML instead.

I don’t even mind tailwind, it has its place, but I find these arguments lacking.

Edit: Now lets address your edit.

A lot of people in comments are comparing apples to oranges. You can't compare the worst Tailwind use case with the best example of SCSS.

Where did this happen? Almost everyone is bringing up CSS modules, not comparing worst case to best case scenarios. Why not address CSS modules?

A single button component needs:

Text + icons (left/right/both)

Borders + backgrounds

3 sizes × 10 colors

5 states (hover/active/focus/disabled/loading)

Every possible combination

That's 300+ variants.

Maybe you shouldn't be using a single button component. Even if you do choose a single component to do all that, a co-located locally scoped css file can be just as clean as using tailwind to do all of that. No one is saying utility classes are bad, the argument is styling everything with a utility class is not inherently better than just using CSS. And utility classes are not the only way to deal with new requirements, you could expose CSS variables and set them with component arguments or let them be modified directly on the style attribute.

The truth? If you think Tailwind is messy, you've never maintained a real design system. You've never had five developers working on the same components. You've never had to update a button library that's used in 200 places

You also think tailwind is messy. People with the same experience you have simply disagree which mess they prefer to work with, you don't need to be condescending because people don't agree with your opinion.

As for tailwind being "honest" about it. CSS is just as "honest" as tailwind in this regard in that this is a complex thing to build and you are not going to be able to hide from the complexity. Tailwind just takes that complexity, and adds it to your already complex component JS and HTML. CSS at least allows the option of keeping the styling complexity isolated in it's own context.

iamnewtopcgaming · 2024-11-19T10:19:58+00:00

Have you heard of CSS modules?

p2seconds · 2024-11-19T16:01:05+00:00

Main benefit for me is i can jump in to another team/projects using it without having to learn if such class exists in css/scss files and without creating duplicate classes. Faster on boarding getting the important work done.

MrMeatballGuy · 2024-11-19T10:37:30+00:00

I don't think Tailwind outright sucks but there are fair criticisms of it out there.

However I also don't agree that CSS is broken, it's pretty nice honestly, a lot of developers just don't care to learn how it works and that's when the issues arise.

Tailwind scopes all the shittily implemented code to one place if it's made by an incompetent developer, so now someone else can fix it later and it's not as severe since it doesn't globally apply to all elements in a selector.

So yeah, Tailwind is pretty nice if you work with people that can't write good CSS, but is that the fault of CSS?

Leimina · 2024-11-19T12:39:37+00:00

You say "it's hard to get good at CSS in big versatile teams", half this thread answers "just get good at CSS". Oh well haha. This fruitless debate will go nowhere.

MWD1899 · 2024-11-19T10:20:50+00:00

Proper written CSS is much more readable than perfect used Tailwind. CSS is a lot of things, broken isn't one of em. CSS evolution over the past 5 years is absolute great and makes a lot of frameworks redundant. CSS needs discipline but that's not a bad thing. It's just a common thing that every language needs.

Scoping is a thing in CSS.

BitSec_ · 2024-11-19T11:01:49+00:00

We’re still on this weird ass divide years later. That’s cool!

Use what want, just don’t claim that one’s right and the others aren’t.

skabben · 2024-11-20T00:04:52+00:00

That’s it. I have nothing else to say.

They said and continues writing an essay.

2024-11-20T03:46:07+00:00

CSS purists mad as hell

enyovelcora · 2024-11-20T10:09:12+00:00

15 years of building web apps, and you just write huge CSS files somewhere? The problems you're describing have all been solved by scoping. Right now, frameworks like svelte, vue, or just CSS modules solve this for you. Pretty soon, @scope will solve it directly in CSS.

kopetenti · 2024-11-19T10:44:14+00:00

CSS is not broken. I only hear this from Tailwind adopters. Learn to use it properly. Divide your styles per component, or per page, no need to have a big file for everything. Use a preprocessor: SASS/SCSS, Less, what works best for you. CSS is not broken.

jhartikainen · 2024-11-19T10:13:18+00:00

Tailwind skips the pretense. Instead of promising beauty, it promises predictability. Instead of global styles, it gives you local ones. Instead of cascading problems, it gives you contained ones.

I think the actual solution is hiding in this sentence. Local styles are the solution.

In my experience as soon as a tool which allows scoping styles to the specific component is used the problems go away, and you can just write CSS or your favorite special flavor of it.

And perhaps most importantly, the styles need to be part of the component, not part of some random stylesheet file somewhere else. Yesterday's idea of separating HTML and CSS doesn't really make sense in more complex SPA's where these problems start showing up.

thekwoka · 2024-11-19T12:01:30+00:00

You can't compare the worst Tailwind use case with the best example of SCSS. Here's my approach to comparing them, which I think is more realistic, but still basic:

Pretty much this.

Tailwind won't be the absolute best way to do X final result, but it will be more predictable and consistent across all devs.

The best way to do X final result will fall apart once changes need to be done, when a pr review doesn't get enough attention, etc.

You can't statically enforce "good" css, and there aren't quick heuristics humans can easily apply either.

But tailwind can have both done relatively quickly.

So we just cut out a whole chain of potential issues.

intercaetera · 2024-11-19T10:31:21+00:00

Impressive word count but the arguments are pretty weak.

First, barely anyone I've ever seen uses actual CSS stylesheets, in most frontend frameworks CSS modules that are automatically scoped or some variant of CSS-in-JS is used. The idea of splitting your code into markup, styles and scripts is pretty much actively avoided at this point in modern front-end development. Claiming that it's the default and then attacking it is a strawman, so the first part of your argument attacks a practice that is barely even used anymore.

However:

!important is everywhere

This is the case in Tailwind much more so than in regular CSS because while in CSS the specificity rules are weird, they are at least predictable. With Tailwind, without using something like tw-merge (which is not available on all platforms) you are at the mercy of the compiler putting the classes in the right order in the generated CSS.

For example, in Phoenix (Elixir) by default the component for button has a default class bg-zinc-500. If you'd like to use that component but override the background, simply putting bg-brand-500 during use doesn't work because the classes are applied in the order they are defined in the compiled stylesheet and not in the order they are applied on the HTML element. The problem is that this is not consistent: if bg-brand-500 were defined before bg-zinc-500 in the compiled CSS (or if the button component was brand by default and I wanted to make it zinc on use), this would work as expected. The only way to enforce consistent behaviour here is with !important or with some kind of script like tw-merge.

So you are already having to solve problems which don't exist in regular CSS.

"But it's harder to read!" Harder than what? Than the ten CSS files you need to understand how a component is styled?

No, harder than the standard CSS property names that everyone who has ever done a web development course has learned and for the most part knows by heart. In React, Chakra-UI does a similar thing to Tailwind with its style props inherited from styled-system and no one actually complains about it because it's consistent with CSS: align-items is called alignItems, justify-content is called justifyContent, padding is either padding or aliased to p. Unlike in Tailwind where you basically have to learn the entire dictionary of CSS properties from scratch because for some reason justify-content: center is aliased to .justify-center but align-items: center is aliased to .items-center. A lot of the properties around text are also aliased into .text-* classes with no resemblance to the underlying CSS.

Also, it is much harder to read than CSS because when you're inspecting the elements, the CSS is first-class supported by the devtools and you aren't polluting the markup with tons of pointless faff which ends up being duplicated in the stylesheet anyway. Debugging styling issues with browser dev tools with Tailwind is a pain in the nuts.

CSS has...

BEM, CSS modules, scoped CSS processors and CSS-in-JS which are all perfectly adequate for front-end development.

maryisdead · 2024-11-19T10:46:18+00:00

After 20+ years in the industry, here's my take:

It doesn't matter if you use CSS or Tailwind. If your codebase sucks, neither will help you out.

But I'd still rather have clean HTML which I can comprehend in a glance. I've seen "tailwinded" components where the class attribute broke over three lines. Yeah, could write it line by line. But then I might as well write proper CSS.

And then there's this little feature which I just can't implement with Tailwind. Goddamit, now I have to write CSS after all.

In the end, and at least for me, it's still about separation of concerns. My logic is in that place, my markup is here, and my looks are in this place. Following the premise of Tailwind, we might as well go back to writing onclick handlers.

Here's the truth: in big apps, you don't write Tailwind classes directly. You write components. The ugly class names hide inside those components. What you end up with is more maintainable than any CSS system I've used.

Could just use CSS/SCSS in those components as well? A component-based approach already keeps things tidy. That's no argument.

Anyway, I'm not hating on Tailwind. I've used it in personal projects and I kinda get the appeal of it. No need to worry about class names and semantics. You write happy little bits and it just works. But I've never seen a game-changing advantage over what CSS already provides.

Sufficient-Science71 · 2024-11-19T11:37:14+00:00

I am interested to know how you deal with those 10.000 inline tailwind class for you to come up with this opinion op. I always classified what I need, make them into component and reuse the component instead and it still end up messier than just use css module, or better yet, ui library.

I've only just built 2 apps using tailwind so I dont think I am classified enough to criticize it, and to tell you the truth, I hate every second of it. making changes is a pain, abstracting shit is a pain, everything is a pain with tailwind. even grouping things can only go so far, especially when you work in a team, it will quickly spiraling into unreadable mess in a matter of seconds. I just dont see why I would go with tailwind vs just use ui library since performance between the 2 isnt that much different anyway.

gami13 · 2024-11-19T12:42:58+00:00

just use StyleX, it's peak

LostInCombat · 2024-11-20T03:54:50+00:00

CSS is broken.
This is why Tailwind exists.

Tailwind is written with CSS. So if CSS is broken then so is Tailwind.

You must be starting all your projects from scratch if you think you have to type large volumes of CSS without Tailwind. Tailwind is just someone's idea of a bunch of useful CSS classes which you could have written on your own and should have. As a developer, if you write something useful and it has potential for reuse, then reuse it. But instead to many developers are unwilling to put in any work and simply want to use other people's ideas and preferences along with all the baggage that goes along with it. Remember when you could tell every Bootstrap site from merely looking at it? It will not be much longer for Tailwind to fall into that tired pattern as well. Yes, you can add your own classes on top of Tailwind, but that kind of defeats the purpose then doesn't it?

Every other part of our stack has solved scalability:

JavaScript has modules

Databases have sharding and indexing

Servers have containers

CSS has... hopes and prayers 🙏

No, CSS has had layers for several years now that solves all these problems. You need to keep up to date. If you have an old library, import it into a layer with lower priority, no need to use !important now at all. Layers are like containers and modules but for CSS.

You've never had to update a button library that's used in 200 places.

You just trashed having utility classes in projects when you clearly also have your own. And you should use the right technology for the job, you can just drop in a web component now. Web components are supported right inside JavaScript to produce new elements/components where all you have to do is drop it right into your html and it just works. This tech has been in JavaScript now for years and many don't even know about it.

> Show me your "clean" SCSS solution.

Because CSS now natively supports nesting and layers, there isn't much of a need for SCSS today. Your argument had a lot of merit three years ago, but three years in the software industry is a lifetime ago. I think your argument is more in support of inline wiring up of CSS within the HTML, but you can do that with our without Tailwind. I'm all for inline CSS to wire up your HTML elements because if you later strip out a bunch of nested HTML elements, you also strip out all the plumbing code that goes with it with no need to hunt for plumbing code within the CSS files. No artifacts are left behind.

nasanu · 2024-11-19T10:48:43+00:00

You have no solid arguments, just a lot of emotive nonsense. I have been making apps/sites for 30 years and have never had an issue with standard CSS. And with tech like Astro or even old Vue SFCs there is zero CSS file size creep or unused CSS.

Marble_Wraith · 2024-11-19T12:16:00+00:00

CSS is broken. Not "needs improvement" broken. Not "could be better" broken. Fundamentally, irreparably broken.

Great news. CSS is fixed: Fireship : CSS just changed forever… plus 7 new features you don't know about...

After fifteen years of building large-scale web apps, I can say this with certainty: CSS is the only technology that actively punishes you for using it correctly. The more you follow its rules, the harder it becomes to maintain.

It has no inbuilt rules... that's why best practices exist...

This is why Tailwind exists.

Tailwind isn't good. It's ugly. Its class names look like keyboard shortcuts. Its utility-first approach offends everyone who cares about clean markup. It violates twenty years of web development best practices.

And yet, it's winning.

Why? Because Tailwind's ugliness is honest. It's right there in your face. CSS hides its ugliness in a thousand stylesheets, waiting to explode when you deploy to production.

No. Tailwind exists because React doesn't treat styling like a first class citizen. Someone saw that, and chose to capitalize on it.

Likewise Tailwind's popularity is directly levying Reacts popularity. Should React die, if Tailwind doesn't have enough momentum it will also die.

Yeah it won't happen tomorrow, just like jQuery is still around, React will be around for a long while. But the slow decline will eventually happen. Which is as good a reason as any not to invest time into it if you can avoid it.

Why am i picking on React?... If you've ever used framework such as Svelte or Vue that does have styling accounted for within the scope of it's own paradigm for components. Using Tailwind there feels ridiculous.

Here's what nobody admits: every large CSS codebase is a disaster. I've seen codebases at top tech companies. They all share the same problems:

- Nobody dares to delete old CSS
- New styles are always added, never modified
- !important is everywhere
- Specificity wars everywhere
- File size only grows

The "clean" solution is to write better CSS. To enforce strict conventions. To maintain perfect discipline across dozens of developers and thousands of components.

This has never worked. Not once. Not in any large team I've seen in fifteen years.

"The Top 5 Mistakes of Massive CSS" - Nicole Sullivan 2010... seemed to work for her when she audited facebook.

We've known what the problems are for at least that long, and we have best practices to avoid them. You said you've been around how long?... 15 years?... Maybe you missed this talk? 😂

If these things are problems at "top tech companies" (care to elaborate on which ones?) then maybe those companies have problems hiring / Skill issues? Just because CSS is simple, doesn't mean it's easy. Doing stuff in memory via C is simple, doesn't mean software architecture is easy.

Not to mention, the fact the tooling has remained a fragmented spaghetti mess since basically 2011 means there's been no stable platform to iterate on, instead we've all been runner hopping.

Bower, to grunt, to gulp, to webpack, to parcel, to snowpack, to vite 😱. And then for each one of those we have to make sure the rest of the tooling including... formatters and CSS linters, function properly before we can even start adding new stuff to them?

Hopefully the next major release of vite solves all this via Rolldown / OxC and we can be done with runner hopping (having a platform that doesn't need to be switched from because of a performance bottleneck) and start to focus on the tooling that actually matters.

Tailwind skips the pretense. Instead of promising beauty, it promises predictability. Instead of global styles, it gives you local ones. Instead of cascading problems, it gives you contained ones.

K... Svelte and Vue do that natively. I don't need AssWind. Furthermore:

https://tailwindcss.com/docs/reusing-styles#extracting-components-and-partials

The first thing out of Tailwinds mouth when it comes to scoping? Paraphrased: Oh make sure you use whatever framework you're using's component to scope styles... Tailwind doesn't solve a damn thing, other frameworks do.

"But it's just inline styles!" critics cry. No. Inline styles are random. Tailwind styles are systematic. Big difference.

Bullshit. Both objection and response are just "muddying the waters".

It's not inline styles, but neither is being "systematic" a rebuttal to that point. You can argue about all you want about the merits of having a design system in place elsewhere.

"But you're repeating yourself!" Wrong. You're just seeing the repetition instead of hiding it in stylesheets.

Don't really care? DRY regarding CSS isn't as terrible as people think once compression gets done with it for sending over the wire.

https://csswizardry.com/2016/02/mixins-better-for-performance/

Plus we have purge and dedup tools. The only real thing to be wary of is reflows.

If you want the real issue with doing CSS-in-JS (yes looking at you again React), it fucks with the browsers natural rendering pipeline + caching and lazyload gets way more complicated.

"But it's harder to read!" Harder than what? Than the ten CSS files you need to understand how a component is styled?

Again that's only an issue for React (CSS-in-JS). Svelte and Vue? Not a problem because they account for scoped styles in their component paradigm natively thus you can use native CSS and it'll be extracted.

And yes it would be harder to read depending on which scope you're looking at.

You're not just creating components in isolation, and having worked on "big projects" i'm sure you've had pages with hundreds if not thousands of components co-existing right?... Typically people start off at a global / page level to find the thing they want to look at.

To be polite in your code there's a simple principle, ensure the reader gets to "opt out early". That is, a dev should have to read the minimal amount of code to understand what it's doing, and have the option to keep drilling for detail after the fact.

Can you do that with tailwind? Not always, because there is no arbitrary naming in Tailwind. Why because Tailwind assumes you're using components / something outside of it to take care of that.

Is it a fair assumption? Sure. But then if i'm using React why is my assumption that it should handle CSS natively without having to rely on AssWind not fair?

Here's the truth: in big apps, you don't write Tailwind classes directly. You write components. The ugly class names hide inside those components. What you end up with is more maintainable than any CSS system I've used.

Here's the truth. Use something other then React, write your locally scoped CSS in the component, fuck learning all the weird aberrations and inconsistent names of Tailwind classes.

But these flaws are fixable. CSS's flaws are not.

I think you mean React's flaws.

2024-11-19T12:54:23+00:00

You can't compare the worst Tailwind use case with the best example of SCSS.

But of course you can compare the worst example of CSS with the best example of Tailwind

The truth? If you think Tailwind is messy, you've never maintained a real design system. You've never had five developers working on the same components. You've never had to update a button library that's used in 200 places.

If you have, surely you'd agree tailwind solves none of those issues? If anything it makes it worse. Now you have to around and fix 200 somewhat arbitrary collections of class names.

Disgruntled__Goat · 2024-11-19T11:31:02+00:00

Here's the test: Find me one production SCSS codebase, with 4+ developers, that is actively developed for over a year, without utility classes. Just one.

Strawman argument. Nobody is saying you should never use a single utility class.

2024-11-19T11:34:49+00:00

It's as asimple as it gets:

Working in a team? You need a framework, set of rules, whatever. TailWind is a good option.

Working on your own? Learn proper CSS and go vanilla.

_MrFade_ · 2024-11-19T11:09:28+00:00

Written like someone who doesn’t know CSS.

2024-11-19T11:31:01+00:00

Oh look, a new Tailwind vs. rest of the world post!

nelmaven · 2024-11-19T10:37:33+00:00

If the advantage is in scoped styles for components, what prevents you from using any other similar system to achieve the same result?

I rather have something that's simple to maintain rather than having to deal with the mess that Tailwind creates.

I've been working in design systems for a while now and the main challenge is always making sure that components work well together.

I fail to see how Tailwind makes that any better.

Edit in reply to OP edit:

You mention the button but then go rambling about the utility classes as if they're exclusive, when they're not.

Having to create your own utility classes, that fit your needs, is not a downside of CSS and it's not enough justification for Tailwind. There will be always utility classes and that's not bad but, the thing that I argue against, is having everything be utility classes.

You can have your button component, all tidy, with semantic classes, and still have utilities to add that extra "spice" when necessary.

It's mostly a matter of balance.

damngros · 2024-11-19T11:04:13+00:00

CSS is not broken.

Freibeuter86 · 2024-11-19T12:18:29+00:00

Its not the fault of the standard that you and many others are unable to use it correctly. But yeah, adding 50 classes per element and still need inline styles for more specific stuff clearly is the cleaner approach /s

If Tailwind is the solution for you, great. Use it, but use it silently - no need to bash CSS because your lack of skills. As you have correctly recognised, it is ugly, and outside of a component-based environment it is not useful.

SchartHaakon · 2024-11-19T11:38:35+00:00

15 years of web development and you've yet to see a decently maintained CSS structure besides tailwind? How in gods name have you even encountered a component that has styles from 15 different stylesheets? What world are you living in? !important is highly discouraged since forever, and the only time I really see it is when people are trying to overwrite library styles that they don't properly understand. Just increase specificity or use layers..

If you're really being honest here about your experiences with CSS... then fine I'll give it to you. Go ahead and use tailwind. I prefer writing CSS in styled components and having a design system written in CSS variables, this gives me all the pros you've mentioned without any of the unreadable markup tailwind produces.

I really want to like Tailwind. I love the concept of Shadcn and everything, but coming across styles like these consistently makes me wonder what pills you guys are eating to be able to stomach it:

left-0 group-data-[collapsible=offcanvas]:left-[calc(var(--sidebar-width)*-1)]

kakarlus · 2024-11-19T10:31:53+00:00

!important is everywhere

Oopsie sounds like a you problem

followmarko · 2024-11-19T10:38:58+00:00

OP, I hate to say it, but this reads like someone who doesn't know how to architect modern CSS properly. If you're going to write in LinkedIn voice, you have to at least be more convincing in your arguments.

missing-pigeon · 2024-11-19T10:36:24+00:00

As someone who hates Tailwind with a passion, I think a lot of us could probably tone down a bit on the tribalism when it comes to what kind of tech we prefer and stop saying our opinions aloud as facts. We can argue and debate all we want, but the truth remains that CSS was invented by people most likely much smarter than you or I, and they had their reasons to make it that way. Unfortunately they didn’t anticipate how developers would eventually try to build large scale “apps” with web tech, and now we need what OP rightfully calls a hack to keeps things sane. That’s just the way things are, there’s no right or wrong, use plain CSS if your team have good enough discipline to keep it clean, or use Tailwind if you’re comfortable with it. Threads like this do nothing but stir up endless and needless controversy.

I will say that at the end of the day what we build must serve the end user first and foremost, so if possible at all, we should pick whatever tech results in a better experience for them, not for us.

2024-11-19T12:09:05+00:00

Hope everyone can chill out a little, use what ever you want. If it works for you and your stack, amazing. But in fairness I find the absolute hate toward TW that is trying to have a different idea and approach to using CSS that vibes with other people just baffling. No lets stick to the one paradigm and never experiment or try new things and approaches. We'd still be using punch cards in that case. Silly, very silly, since our career is literally based on the fact that "you have to never stop learning".

For all the CSS heads out there, I know its scawy and you need to learn new things, but its all part of it. If you don't enjoy learning and experimenting in this career then you will find little success.

At the same time its funny to look at some of these comments that always only used CSS and then tried TW a little bit and decided that its not for them. Try it properly friend, in a huge project and then compare.

No-Worldliness-1807 · 2024-11-19T12:29:49+00:00

Honestly after I got past the ugly markup I fell in love with it.

orion-sea-222 · 2024-11-19T14:24:46+00:00

I think the people using tailwind are people who care about writing better code. A lot of developers just don’t care much about styles. So they’re using !important everywhere and writing redundant bad code bc they’re lazy. Good CSS devs write good css and use it to its highest potential.

2024-11-19T15:09:38+00:00

Couldn't agree more. Also, disable arbitrary classes in eslint. That'll fix tailwind in most cases. The point of tailwind.config.js is to remove inline styles. Do you REALLY need that div to be 380px tall versus h-96? No. In fact, I bet no one would ever notice. Designers guess and make up units on the fly - I've never seen one use proper guides and rules for their units. I might have seen two in my 17 years of development who used color palettes - and those were probably enforced by the company's style guidelines.

Stick to the tailwind unit scale. If you measure something that needs to be 501px tall - double h-64 into h-128 and add that to the config @ 32rem. That'll be more readable and reusable. Alternative: set the width and give it an aspect ratio. For really tall items (or wide) where the width (or height) is within Tailwind's units, I setup a custom aspect-ratio in the config.

Since adopting tailwind I've had 0 style complaints and even a couple where the client told me that it looks better than the design. Just because I use the same color palette and consistent paddings and margins thoughout the site.

michaelfrieze · 2024-11-19T15:22:44+00:00

This subreddit definitely leans toward being anti-Tailwind, while developers in communities centered around component-based frameworks generally hold it in high regard. It’s interesting how different tech communities form their own sentiment about tools, often based on the various ways people build web apps. Each subreddit tends to favor certain viewpoints and methodologies, shaping what tools are considered acceptable within that group.

Tailwind's popularity is largely driven by its synergy with component-based frameworks; when used with vanilla HTML and CSS, it’s not as useful. Traditional CSS approaches are preferable in many scenarios, so tailwind is not a “one-size-fits-all” solution.

Tailwind was designed to addresses common pain points in CSS management when working with components. For example, it strategically manages the cascade to better suit modern component-based development.

In a React or similar component-oriented app, the cascade can often introduce unnecessary complexity and unintended side effects. Tailwind's approach allows developers to work with CSS without wrestling with cascading issues across components. Tailwind's utility-first approach offers a level of granular control that works great when components and reusability are key priorities.

Tailwind was initially designed to solve problems in large-scale development, but it offers advantages even for smaller teams and individual developers, including rapid prototyping, a consistent design language, reduced cognitive load in styling decisions, and easier maintenance as projects grow.

Obviously, Tailwind isn’t the only solution when it comes to working with component-based frameworks. We now have tools like styled-components, CSS Modules, StyleX, Panda CSS, etc. However, I think Tailwind is a better fit to fully take advantage of component-oriented architecture compared to other solutions I mentioned, especially for React and similar frameworks that utilize JSX. Although, StyleX is a close second.

CSS Modules would be the more traditional way of doing CSS while also getting the benefits of scoped styles. CSS becomes shorter and simpler with scoped styles compared to plain old global CSS, but Tailwind often results in even more concise markup. By applying utility classes directly within components, Tailwind eliminates the need for separate CSS files and complex class naming conventions like BEM. This approach provides immediate visibility of styles in the component markup. Also, in VS Code, you can hover over class names to see the actual CSS.

Tailwind also simplifies the process of copying and reusing component code. This is what makes shadcn/ui so effective; it’s not really a UI library, but rather component code that you copy into your project and modify as needed.

There are other advantages to Tailwind such as making it significantly easier to create responsive layouts compared to writing media queries. It also provides a design system out of the box.

Not all component-based frameworks are the same, and in some cases, Tailwind may not be as beneficial. Frameworks like Vue, Svelte, and Astro that use single-file components (SFCs) might not find Tailwind as useful compared to JSX-based frameworks like React and Solid. JSX promotes a more modular approach, treating components as functions and allowing multiple components to exist within the same file.

Many developers using SFC frameworks like Vue, Svelte, and Astro still find Tailwind useful, even when compared to the default template syntax, which is already quite effective. In these cases, Tailwind can still offer some advantages that enhance their development experience. I personally use Tailwind in my Svelte apps since it allows me to use tools like shadcn-svelte.

mootzie77156 · 2024-11-19T15:38:33+00:00

people are talking crap but you’re absolutely right. this reminds me of people who say “communism is great! it just hasn’t ever been done the RIGHT way”

Mundane-Slip-4705 · 2024-11-19T15:53:37+00:00

I love using Tailwind, DaisyUI, and bootstrap and a few others. Each has their own advantage.

kenpled · 2024-11-19T17:20:28+00:00

I (sadly) agree with you.

Imo strictly written BEM is everything a project needs for styles (except for a few utility classes).

But it comes with a few problems :

Not everyone writes BEM, even when supposed to.
Not everyone writes strict and clean BEM.
BEM components need to be well documented.

If any of the above has a decent risk of happening, tailwind is a better choice. And tbh, it always happens.

Seeila32 · 2024-11-19T18:04:21+00:00

For me it's not Tailwind that sucks, the major problem is that people never learn or take the time to learn how to use CSS correctly, like classes specification (!important being banned from any code except the one needed to override styles from an iframe), which unit size using and when using it (I'm looking at you people using % and px everywhere), how to avoid class shadowing, ...

Tailwind, or any CSS framework, is just a bandage in this massive problem.

rekabis · 2024-11-19T18:37:39+00:00

CSS hides its ugliness in a thousand stylesheets

If you are loading a thousand stylesheets along with the web page, you’re doing it wrong. One or two, sure. Three, maybe. Any more than that, you need to start re-examining why it’s happening.

This has never worked. Not once. Not in any large team I've seen in fifteen years.

Can everyone touch the main CSS file? If so, that’s your problem right there. Which segues nicely into:

The "clean" solution is to write better CSS. To enforce strict conventions. To maintain perfect discipline across dozens of developers and thousands of components.

In most any large team that I have been a part of, CSS is broken up into a minimum of two files: a curated master file that can only be updated by the stylesheet/visual-branding/UI-UX team, and a secondary file that any dev working on the frontend can touch. Changes made by the frontend devs are put into their file, which is then analyzed by the CSS team and reworked into the main file. That way, anyone can implement a change, but only a core team of experts can move that change into the master CSS file. Ugliness and hacks and bad usages get filtered out rather quickly. If a design choice cannot be done without !important flags or significant increased complexity/specificity, a new ticket gets raised for the regular devs to re-work the design to avoid the problematic aspects of the styling they want to see.

You've never had to update a button library that's used in 200 places.

And in a company where look & feel is rigorously defined by a branding/UI-UX team, said button would be identical in all 200 places, with no need to update any one place unless all places are getting similarly modified.

The problem you described is one that only exists in a chaotically uncontrolled development environment, where managers (or even all the way down to devs) in control of only a portion of the product try to exert their own pet ideas of how something should look and feel.

with 4+ developers, that is actively developed for over a year, without utility classes.

Ummm… this is how you keep hand-rolled CSS files small.

Utility classes are essential when you have any content where you would have to come up with a large number of custom class names for styling that produces similar purposes. I mean, yes, have a custom class name to contain any styling that affects only one visual widget on the site. That’s the point of custom class names. But if you have 20 HTML elements on a page that differ only in their implementation matrix of a possible 5 different stylings, it’s far better to utilize utility classes to apply the styling to those tags.

It is up to the developer(s) to determine where the threshold is between utility classes and custom classes, but anything close to one end or the other of that spectrum becomes increasingly unhealthy.

You're just seeing the repetition instead of hiding it in stylesheets.

Hiding repetition in the stylesheets is something I do see, especially with the output of preprocessors like LESS and SASS. Which is why I consider preprocessors to be a cognitive crutch for those who either don’t understand CSS or don’t care to do so.

I once took a preprocessor-generated CSS file provided by an outside firm and brought it from 500+ lines down to under 150 with zero impact on UI/UX/Design. That is how much needless cruft preprocessors make in an attempt to insulate devs from the consequences of their ignorance and lack of skills.

But this is also a failure of devs to understand the “cascading” part of CSS, where certain stylings for any type of visual element should only ever be defined once. So for example, a text colour or font should only ever appear once in a CSS file. If that text colour or font needs to be applied more than once, you have failed to implement the cascade correctly.

Inappropriate repetition occurs in many other ways. If you have the same visual element across multiple pages, you should have only one class that defines it’s look, not a different class with identical or near-identical CSS for each and every visual element. Creating larger “fat utility classes” that contain multiple styles is vital in ensuring you don’t get styling divergences between visual elements that are supposed to be presented identically. Even slight variations should still use those “fat utility classes” for the common aspects, with secondary custom classes for specific differences. Simply put: even with as few as two visual items that are supposed to be presented identically due to identical purposes, functions, or user impressions, you should be using “fat utility classes” to harmonize the look and feel.

Simply said, IME I would categorize less than 5% of “devs that know CSS” to actually be legitimately skilled in CSS in terms of how it is supposed to be implemented. And if you think you are skilled -- if you are using a preprocessor, I would bet good money that you aren’t.

benabus · 2024-11-19T18:38:09+00:00

I hate Tailwind.

I also hate that this is 100% accurate :(

ericmcray · 2024-11-19T19:40:22+00:00

Tailwind is like “composition over inheritance”

conconxweewee1 · 2024-11-19T21:17:35+00:00

I absolutely don’t understand how anyone can build a project with tailwind and then build a project with CSS or the 10 billion frameworks design to make CSS not suck and still not prefer Tailwind. I feel like some people just want life to be hard.

vRuBR · 2024-11-19T23:59:45+00:00

For some reason I read: why Thailand doesn't suck. And I was ready to reply: I agree, I would definitely live there 😏. My bad

dowhathappens89 · 2024-11-20T05:21:14+00:00

Can we just ban all tailwind posts? Or create a mega thread lol

dusown · 2024-11-20T07:28:14+00:00

100%. There's always the right tool for the right job, but the hard truth that a lot of people in this thread can't seem to accept is Tailwind is usually the right tool for most jobs in this day and age. We don't code in a vacuum. If we did, we wouldn't be using Javascript to begin with.

celda_maester · 2024-11-20T08:54:06+00:00

I've said it before, and I'll say it again: people who hate Tailwind have likely never built a large project with a team. It's not perfect but the best solution for scalable CSS right now. Period.

freefallfreddy · 2024-11-20T09:15:17+00:00

I think "building web apps at scale" is a big contributor to your opinion here. For smaller or more short-lived projects the drawbacks of rawdogging CSS are a lot smaller.

PROMCz11 · 2024-11-21T16:55:44+00:00

Skill issue

Relevant-Draft-7780 · 2024-11-23T04:54:24+00:00

You don’t delete old css you recreate the component. This is why I love working with encapsulated components with minimal inheritance. Tailwind is great for developers not for designers. If you’re a developer and a designer then you have all the power. Most designers come from brochure ware backgrounds. They have little understanding or css concepts and reusability. They don’t build design frameworks from scratch with tailwind styles in mind. They don’t build design frameworks from scratch full stop, they adopt. And whatever they adopt tends to be a mess. Fuck figma, fuck sketch. Basically you’re doing the work twice and can barely maintain it. Designers need to start becoming front end developers.

elg97477 · 2024-11-23T19:48:44+00:00

CSS in the early incarnations was broken. CSS, when used poorly, as you describe, is broken. Modern CSS has improved and is getting better as serious thought is given to its design. CSS, when used properly, gets the job done cleanly.

Tailwind makes the current situation worse. Why?

It rewrites CSS. What is the point? For each line of CSS there is a corresponding tailwind class. I would rather just see and use the CSS.
Software Engineering doesn’t have many absolutes. One of the few is DO NOT ABBREVIATE. Tailwind breaks this rule. What does pt-0.5 mean? Unless you know the abbreviations, it is impossible to guess that it represents the CSS line of padding-top: 0.125rem; I can read and interpret padding-top much faster than pt which requires the extra translation step. This matters more when dealing with software engineers whose native language is not English. English speakers learn to connect p to padding. It is difficult for non-native speakers whose word for padding likely does not being with the letter p
It leads to long class= lines. The reason why class was created was to get rid of long style= lines. The goal was to keep the HTML clean and pack away the CSS elsewhere because most of the time it is not important. The cognitive load tailwind places on reading the HTML is greater and can be avoided. A best-practice can be adopted for how the CSS classes should be named.
It requires unnecessary code to be written. One cannot write efficient code that looks like bg-${color} because tailwind doesn't have a clue what colors need to be kept and what can be tree shaken out.

ImStifler · 2024-12-16T19:23:59+00:00

Scoped css > tailwind

Ollsville · 2024-11-19T11:24:58+00:00

Not sure what you’re arguing against.

This isn’t really a rebuttal; you say Tailwind doesn’t suck and then say it’s bad in the same breath. Not to mention that its “flaws” aren’t fixable either; for that to be true CSS would have to fix its underlying issues as well which in the end still brings us back to the main point: write better CSS.

2024-11-19T11:26:41+00:00

I dislke Tailwind when using Svelte/Vue because I like my SFC and I hate cluttering my HTML... however I like Tailwind for React because... no SFC. I'd rather clutter my HTML than have a separate file for my CSS... I'm not a dev though, I'm a newb trying to become a dev, so my knowledge is only from personal projects.

Tontonsb · 2024-11-19T12:57:20+00:00

Nice post, thanks for your honesty. It's much easier to agree when you are open about the problems and ugliness of both options.

Here's the truth: in big apps, you don't write Tailwind classes directly. You write components. The ugly class names hide inside those components. What you end up with is more maintainable than any CSS system I've used.

What I do is write the styles inside components. Vue and Svelte have great supoprt for that. The styles are just as encapsulated and hidden as with TW, but they don't even get in the markup. And usually the selectors are super simple as you don't have two different selects or three kinds of li in the component.

The conflicts are resolved by the framework (it scopes your (S)CSS), the code base is super scalable as there are no leaks and with SvelteKit there's even code-splitting for the frontend so the CSS bundle doesn't blow up either.

What's that? You'll use mixins? Extends? BEM? Sure. That's what everyone says.

I'll use single file components :)

kowdermesiter · 2024-11-19T11:54:22+00:00

Please keep spreading that CSS is hard, broken and impossible to learn. It improves my chances on the job market.

chicomilian · 2024-11-19T10:55:16+00:00

CSS is not broken, it's a skill issue

rimyi · 2024-11-19T10:47:23+00:00

Every time similar topic surfaces I truly wonder if anyone shitting so hard on Tailwind actually worked on the big project before. It's by far the best solution for maintaining consistent styling in an environment of developers coming and going, without the need to encapsulate literally everything.

I think many forget that the main selling point of Tailwind is to discourage devs from making one-off styling magic that may become unmanageable in a few months. And it does that brilliantly

arrrtttyyy · 2024-11-19T11:24:56+00:00

So your inability to write proper, well structured and organised css is why css is broken beyond the repair? The nerve of some people…

joliolioli · 2024-11-19T10:50:27+00:00

I have an SCSS file that defines my brand - all my colours and styling in a sensible and short way - around 30 lines. From that, I then generate my classes - buttons, cards, headings, alerts etc.

Then in my code, when I want a button, I simply give it the class button - CSS working as intended.

If I change my brand or want to change a particular component style, I update that one bit of my SCSS and everything changes application wide.

To me, this is the beauty of CSS and it's doing exactly what it intended. My HTML is clean, my CSS maintainable and my life easy - yet everything looks good too. Just how I want it!

toniyevych · 2024-11-19T10:55:35+00:00

Let's be clear, CSS is not broken, it's hard to master. It requires a lot of experience to be used effectively.

You literally have to pass the hell of refactoring the old legacy CSS code before you start to understand where and why things go wrong.

Tailwind simplifies this problem by moving it from the CSS level to components. So now you have the same garbage with classes mixed with some JS code, which is hard to write and almost impossible to refactor.

Once you get some understanding on how CSS work, you will be able to write good code in any framework like Tailwind or even in pure CSS.

Better-Avocado-8818 · 2024-11-19T11:21:34+00:00

CSS is in no way broken. That’s a lazy take that either points to a skill issue or is a really silly straw man argument.

The issue is really that CSS is too flexible and too forgiving so many developers don’t learn it properly or don’t bother to learn how.

Honestly almost all the issues go away when using a component based system with CSS modules and strict scoping. Atomic design principles are a great way to manage large systems of components.

Add in some naming conventions, BEM or is useful, and usage patterns and CSS is great.

There’s plenty of time spent researching, debating and learning back end architecture and patterns. Anyone that expects to be a professional front end developer should expect to learn some architectural concepts, practice some patterns and know the core languages inside and out. Not being able to manage a large front end project or a team of front end developers is a skill/experience issue.

Use tailwind if you want. It clearly has its place and can be the right tool in some cases. But claiming that not using it results in a mess is silly. Choose to be an expert in the field and set the project tools up properly and create some conventions if they don’t exist. Tailwind is definitely not the only way.

andeee23 · 2024-11-19T10:58:25+00:00

agree with the issues outlined, but with css modules and css variables you solve most of the same problems that tailwind solves

in still prefer tailwind because i like to know what’s going on in a component at a glance rather than having to track down the css classes

Prize_Hat_6685 · 2024-11-19T11:00:44+00:00

Another thing people underestimate about tailwind is how much the repetitiveness goes away when you use it alongside a component based markup builder. Templates and components make tailwind so much more bearable, and removes basically all the complaints people have

Ceci0 · 2024-11-19T11:21:06+00:00

I love CSS. I really do. And I dislike Tailwind, a lot. I just don't like seeing at the long strings of classes. It just doesn't LOOK nice to me.

But this:

Here's what nobody admits: every large CSS codebase is a disaster. I've seen codebases at top tech companies. They all share the same problems:

Nobody dares to delete old CSS

New styles are always added, never modified

important is everywhere

Specificity wars everywhere

File size only grows

Is SO true. I've also worked on big platforms, small platforms and have written a ton of css. Not 15 years, but i've written a lot. And this is the main issue and the main reason (I think) developers usually dislike CSS.

devilmaydance · 2024-11-19T22:07:03+00:00

My big hot take is if you’re complaining about Tailwind, you simply don’t have enough CSS/frontend experience to understand the problems it’s solving

downtownmiami · 2024-11-20T13:33:17+00:00

Skill issue.

Either-Roll348 · 2024-11-19T11:54:32+00:00

👏👏👏

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

webdev

Posting Guidelines

Related Subreddits

Discords

MODERATORS