[734129837261]

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test.

The best arguments against it:

1. Spamming utility classes causes horrible git commits, git history, git difference checks;

2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted;

3. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. And since there is no context to it, it'll be hard to JUST replace them where you would want them to.

Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful.

In almost every single use case, using vanilla CSS or SCSS is far superior. For React projects (and Vue.js, and Svelte, and Angular), I'd recommend anyone to just use (S)CSS modules. It's so elegant and doesn't come with any of the disadvantages.

Except maybe a slightly larger package size. Minimally so. Your framework of choice should be (or allow) code splitting to take place. And a few bytes more or less aren't going to make or break most websites.

[onion2k]

It's loved by novices and those who don't know what they're doing, almost exclusively.

I've been a frontend dev for 25 years and I quite like Tailwind. I'm not sure which category I fit into. I think it might be both.

Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches.

This is a really good example of where Tailwind is actually quite nice. Imagine if you didn't use a utility class, and instead you'd written your styles in plain old CSS or SCSS with "padding: 8px;" everywhere on your years-old-built-up-to-thousands-of-styles design. Replacing those is easy enough, but what about your SCSS mixins? Your CSS calc()s? The places where someone thought an element needed a bit more padding and used "padding: 9px" instead? Manually managing styles is hard. Tailwind makes it a bit easier, mainly because it encourages consistency and removes variability. Finding and replacing a "p-4" everywhere is trivial, and if you've used a library well rather than rolling out an ad hoc mix of things you can be quite confident your change will work everywhere. It's far from perfect but it's quite a well-thought out approach.

[diob]

They "No true Scotsman" started their argument, so I think you're fighting uphill.

I have around 10 years experience, tailwind is a godsend for maintainability and speed.

[kypro]

Variables would be the obvious answer here.

If you're applying `p-4` to all your component classes you're only marginally improving on applying `padding: 8px` on all of your component styles. Both are terrible solutions even if one is slightly better than the other.

I generally agree with OP. Tailwind is horrible for larger projects and I have no idea why it's so well liked. The utility class approach is bad, and naming of their utility classes is even worse.

For smaller projects or for prototyping it's okay, although even then it's only slightly better than inlining styles.

[karaterobot]

Pretty much every CSS framework I've ever seen (and certainly every CSS-in-JS solution I've ever seen) has as its underlying premise "we know you hate CSS, and want to avoid thinking about it as much as possible". For people like me (and perhaps you) who actually like CSS, our reaction is "why would I ever want to use something that abstracts away the power and flexibility of a thing I enjoy using?"

The problem is that I think we are outnumbered. Most engineers want to avoid CSS, pretend it doesn't exist, and if all else fails, build a complicated mech suit they can climb into to manipulate it without coming into contact with it directly. That's why things like Tailwind and Bootstrap and CSS-in-JS solutions took off.

My solution on the teams I worked with was to say "hello, I will do all of the CSS in the entire application if it means we don't have to add another dependency just to indulge the team's distaste for CSS."

Near the end of my career I was pretty much just doing CSS all day. I liked it, but probably what I did was create a terrible situation for whoever came after me. They still hated CSS, were bad at using it, but now had to maintain a lot of it. We probably should just have consented to the convenience of the majority even if (as I still maintain) they are wrong.

[mind-blight]

I actually think a lot of CSS-in-js frameworks became popular for the same reason that React became popular: css, html, and to some extent JavaScript can't really be decoupled.

Things like CSS Zen garden made it seem like they were, but that was only a separation of control. If the HTML structure changes, then the CSS likely needs to change. That's a tight coupling.

CSS-in-js embraces the coupling and makes it explicit instead of implicit, which makes refactoring safer and speeds up development.

edit for typo

[sorahn]

> Pretty much every CSS framework I've ever seen (and certainly every CSS-in-JS solution I've ever seen) has as its underlying premise "we know you hate CSS, and want to avoid thinking about it as much as possible". For people like me (and perhaps you) who actually like CSS, our reaction is "why would I ever want to use something that abstracts away the power and flexibility of a thing I enjoy using?"

I don't find this to be the case with styled-components. To me styled components feels just like writing CSS (which I like), but with a slightly obscure variable syntax (if I need a prop or theme value).

[bluetidepro]

> It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test.

This is an incredibly silly take. As a senior frontend dev with almost 20 years of experience and a solid resume, I will take Tailwind over anything else in most cases. Obviously there is always exceptions based on the project needs, but to have such a hard take like this just cracks me up at how narrow minded it is.

[hbn]

I really don't get the "tailwind is for beginners" opinion I see parroted so much.

It doesn't enable you to do anything that CSS didn't already do. It's just a different way of writing it. Knowing CSS is a prerequisite to being able to use Tailwind.

"Tailwind is for beginners" just sounds to me like "I don't like this thing because I'm too smart for it"

[nirvdrum]

I've been doing front-end development in some capacity almost as long as you, but it's not my forte. I've looked at Tailwind and I can see its value as a way to quickly prototype, but it also looks to violate the deeply instilled belief I have about semantically named classes. I know front-end development has changed its set of best practices several times now. We went from unobtrusive JS and semantic class names to modular CSS and CSS in JS, along with heavily marked up HTML to help out JS frameworks. Maybe this is just the pendulum swinging again. But, I'd appreciate any insights you can share on how this helps lead to maintainable software. The string of utility class names on various elements doesn't click for me the same way a class named "sidebar" or whatever would. But, a lot of smart people like it, so I assume I must be missing or overlooking something.

[Retric]

I have 20 years of front end dev work and consider myself a CSS novice as I think the overwhelming majority of people are.

If you haven’t read and understood the spec then like most people you don’t know CSS, which is fine. It’s not a question of knowing what say conic-gradient does, but how browsers use CSS in depth.

[rndmize]

> I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test.

As a long term front-end dev who likes tailwind, I find this fairly offensive. Your second and third points sound like problems with CSS in general.

> Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful.

If I'm using tailwind on a project, I don't want more power. I want less. I want simple constraints that give me solid basic styling without constant adjustment. The adjustments I _do_ want to make should be easy. The options available should be good options, not all options. I don't feel like fussing with box-shadow for the umpteenth time to get something that looks nice, or poking at my margins or padding or gap until it works with the rest of the page. I don't want to come up with a grid system again, or a color set, or a bunch of variables to extract these from the custom classes so they see proper reuse and are easily available; I want them already done.

[lvl102]

I don’t think you realize that there are a lot of old school developers such as myself (going +25 years) who’s simply looking for quick and dirty front end tools that simply work and get out of the way. Tailwind does exactly that.

[icedchai]

I'm in the same boat, and Tailwind looks like something that would get in my way (or at least becoming annoying very quickly.) I don't want the equivalent of inline styles all over the place.

[postalrat]

How does it not get in your way? If you ignore it?

[eiiot]

> Spamming utility classes causes horrible git commits, git history, git difference checks;

As opposed to what? This is still an issue with any kind of utility class, where the alternative is inline styles or CSS-in-JS, both of which are substantially worse.

> Conflicting utility classes aren't clear, and sometimes the order cannot be trusted;

This is fixed in the IDE with tools like ESLint. I have VSCode setup to automatically reorder Tailwind classes, and it works great. (It even moves broken classes to the front of the list, so you can immediately identify if they're working or not)

> Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. And since there is no context to it, it'll be hard to JUST replace them where you would want them to.

This is an issue with CSS in general, especially CSS modules. Plus, if you use tailwind correctly (with @apply) you only have to update it once.

> Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful.

With tailwind, you still have access to `calc()` and variables with their bracket `[]` syntax. It's just much easier to do everything else.

[atsjie]

> if you use tailwind correctly (with @apply) you only have to update it once.

"Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly."

That is straight from the Tailwind docs: https://tailwindcss.com/docs/reusing-styles

Using @apply a lot just reinvents CSS; that's not the point of Tailwind.

I can write similar comments about the rest of your statements, but I think you're too narrow minded to accept any input so I won't bother.

[naasking]

Sounds like you don't know how to use Tailwind. Any front-end app is almost certainly already using a templating language, so declare your aggregate shared styles as variables there. Now you don't have to repeat your long style declarations in every context, and your 100 different markup files don't change if you want to make a minimal stylistic tweak (handling your point 1+3).

Yes, you can do this sort of thing in CSS and SCSS, but you're already using a templating language that can do this job, so why are you pulling in yet another tool (SCSS), or why are you requiring the mental context switch to yet another language and another file (CSS) when you can stay directly in template you're actually working on?

In other words, by removing CSS from the full stack of template language+programming language+HTML+CSS+JS, you reduce the cognitive overhead and context switching needed to actually get stuff done. If you add htmx you can also remove most of the JS too, thus reducing cognitive load even further.

[mixmastamyk]

Happen to have a blog post link handy? Would like to see this strategy in more detail. With something like Django if possible.

[richeyryan]

I've been working with CSS since floating grids were a thing. I've worked on projects with SASS/SCSS doing the whole BEM thing and then using CSS/SCSS modules. I have a good working knowledge of CSS. I like Tailwind. It's system for colours, and spacing is a good sane baseline, and you can customise them to conform to your design system if you want. CSS grid makes layout much easier in general, but their utility classes make it trivial to express your grid layouts.

I can't say I've really had many issues with git diffs or conflicting classes. I'm not entirely sure why you'd replace blanket `p-4` all over your app. Are you making some changes to the spacing in your design system? Why not change it globally and let it propagate?

I'd tend to agree with you that (S)CSS modules are a great improvement over the completely detached styling of the past, but I still think Tailwind has a lot to offer with its prebaked system and dead code elimination.

[adwww]

I'm not super up to date with frontend development trends, but when I used it recently it really went against everything I've ever been taught about separation of concerns.

Like, I thought we were supposed to keep our content and styles separate, not mismatch them all together with a thousand utility class imports.

[atsjie]

This has changed a number of years ago.

Basically it's a component-mindset; create some file with everything in it so that in the rest of the app you can just use `<MyButton>...</MyButton>`.

The `<MyButton />` file takes responsibility for everything it does (logic, handlers, markup, style).

However; this does not mean these files should grow large. Instead when things become too big (say over 250 LoC) you split up responsibilities by sub-components.

It's basically dividing problems in ever-smaller problems, but NOT by separating by technology (html/css/js).

Separation of concerns is horizontal slicing of the app architecture, components however slice the architecture vertically.

[naasking]

Consider whether those lessons were actually informed by evidence. Tailwind is not like inline CSS, the latter has a number of downsides because it doesn't permit you to access all of CSS, where Tailwind does.

[troysk]

The code to content ratio goes for a toss as well resulting in poor seo. Many say that it should be used to make components and not spam with utility classes. I'd rather use CSS modules and write CSS directly as it provides far more options.

[cactus2093]

> 3. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches.

I'm not necessarily a big fan of Tailwind, but this is a total strawman. Nobody would advocate having one big file with thousands of repeated classes or something. Just like it would be a strawman against the use of css variables to say that you'll end up with a bunch of global variables used in thousands of places that become impossible to change because you can't be sure you won't break something unintentionally. And in the extreme cases where it does happen, the latter scenario is often much worse of a problem IMO than having too much repetition, you can always get clever with find and replace to get through repetition.

Tailwind works when you use it with a component framework, you're not getting rid of all abstractions completely you're just moving them all to a single layer within the component class.

But both approaches still make it possible to shoot yourself in the foot and end up with a mess of unmaintainable code if you don't abstract things well.

[dimmke]

So, I am a very experienced front-end developer with quite a bit of CSS expertise and I have been using Tailwind on a project, and I actually quite like it.

It lets me design things in browser in a way that nothing else I've ever used has. Precisely because of my CSS knowledge, I know how to do everything, it's just a matter of finding the class name for it (referenced post talks about having to look up docs a lot, I relate.)

There's also a lot of established UI patterns, so I don't have to reinvent the wheel. And I often do roll something up into a semantic class name when I know I'm going to reuse it a lot. For example, I have a .container that is a list of @apply'd tailwind classes. PostCSS gives a lot of flexibility.

But I mixed things. So I have media queries that affect that :root font size and that decreases the amount of element specific responsive work I have to do.

I should mention I'm also working in Svelte, which has the ability to scope local CSS at the component level. It's a delight. So I mix and match between utility classes and scoped (dynamic classnames get generated) styling.

[jmull]

You're welcome to hate tailwind all you want, but don't let that cloud your judgement.

Plenty of very experienced developers like it just fine.

[matthewmacleod]

I can't actually disagree with you on this – as someone who had a robust SCSS module workflow and a set of utility functions in place already, Tailwind makes a bunch of stuff worse and makes little obviously better. It's surprisingly clever technology, but I don't like what it does to my code, and I do not in practice see many of the purported advantages of using it.

But I will also say – you need to get over that. It's probably going to be ubiquitous, whether you like it or not. There is some justification for it, it offers some advantages for particular users and use-cases, and it's likely that those advantages are enough to outweigh the downsides in general use. It's not worse enough in the ways that matter. So I've embraced it in the past couple of projects and it's fine – at worst vaguely annoying, and I'm much happier not having to bother hating it any more. Life's too short.

[b1n]

I'm glad to see all the designers on here really hate tailwind. I hope they persuade my competitors not to use it.

I've been writing CSS since IE 5.5 and I was tired of the whole horrible mess. Tailwind goes against everything I learned about the reasoning and benefits of CSS' styled web page design. Tailwind is right. Tailwind is how CSS should have been.

I (and more importantly my customers) do no care about minor differences in padding, or that the markup looks ugly, or that it takes a few extra minutes to parse the git commit (made up for by massive time savings elsewhere). Tailwind gives you a quick way to get a design that looks good enough while maintaining control over the layout of the page.

Need something custom? No one is stopping you from writing your own classes to compliment the utility classes or from moving common combinations of utility classes into their own class.

[satvikpendem]

See also Vanilla-Extract if you use TypeScript, it uses TS instead of SCSS to compile it down to pure CSS (I mentioned this in another comment as well, for reference).

https://vanilla-extract.style/

[theteapot]

> I hate Tailwind with the passion of a million suns.

How much passion does your standard sun contain?

[FredPret]

Enough passion for the feelings engendered by Macromedia Flash?

[pwdisswordfish9]

According to Wikipedia, it’s 15 megakelvins.

[pocketsand]

Those who make claims of the form "X language/framework is used by novices and the incompetent, almost exclusively" fall into two camps: 1) Inexperienced, insecure newbs, or 2) Assholes.

[Kiro]

Tailwind is obviously not just loved by novices. I've done CSS since IE6 and I really like Tailwind. Your "best arguments" are not actually problems. If anything git diffs become clearer because you see immediately what was changed without having to jump between files and lines.

I wouldn't touch SCSS with a ten foot pole in 2022, especially not for React where literally any CSS-in-JS library is better, and I used to love SCSS.

[hk1337]

Do you favor putting multiple tailwind classes on an element or creating your own CSS classes with an "@apply" and what tailwind specifics you want for that class?

[christophilus]

Same. I love Tailwind. Been writing CSS since not long after it was invented. Tailwind solves almost every problem I've ever had with CSS. It's :chefskiss:

[chrisweekly]

Your comment would have been radically better if you'd omitted the first three sentences.

[kaba0]

I think you miss that using components or tailwind is not exclusive. If you have a reusable button than you are supposed to make it a reusable component and have it styled with tailwind at one place only. So your concern doesn’t apply at all.

[pupppet]

My best argument against it is whatever the learning curve, you're better served just spending that time learning to write CSS instead.

[CapnCrunchie]

My understanding of CSS has gotten a lot better from using Tailwind.

[hbn]

It's not a replacement for CSS, it's an extension of it.

You shouldn't use Tailwind if you don't already know CSS.

[greenhatman]

Hard disagree on that one. You can learn Tailwind in an evening.

[super256]

When you pick up tailwind, you will automatically learn vanilla CSS along the way.

[hk1337]

What would recommend for some sane CSS/SCSS defaults?

[hk1337]

Oh, I guess I cannot edit it anymore.

*EDIT* for the above.

What are some typical defaults that I should start with for things like margin, padding, font size? What sort of items should I be initializing in ::root then overriding later?

[rkangel]

Separating markup and styling doesn't work. One is too related to the other. Instead, we have discovered reusable components (what used to be called widgets back when we were doing native GUIs). You have your little bit of markup along with the styling information together for making a button or whatever. And then you use it (with suitable parameterisation). You combine those into bigger components etc etc.

I use the word 'components' because that's familiar to people, but there is a related concept in most modern frontend frameworks. In this world, tailwind makes so much sense. If you do it right, there is very much less in the way of shared stuff that needs find-and-replacing and you're keeping all the information you need to see how something is going to render all in one place.