11 ms·

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

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 4y ago
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.
- kypro 4y ago
  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.
  - 9dev 4y ago
    But p-4 is a variable: you can set the actual padding applied in the configuration file! It doesn’t have to mean 8px, but rather „standard amount of padding“. If you want to use „small amount of padding later on, you’ll use p-2 - whatever that means in your app. That solves the exact problem you and OP complain about, in a neat, configurable, safely replaceable way. Tailwind allows you to separate design intent from implementation values.
    - waboremo 4y ago
      Vanilla CSS also allows this, without any real effort either. Tailwind's power is in its defaults, as soon as you want to start tinkering, you were much better suited sticking to vanilla CSS.
      - 9dev 4y ago
        I didn’t dispute that. I just refuted parents point here.
  - onion2k 4y ago
    Variables would be the obvious answer here. Variables are very cool and super powerful, but they fall down if you need to support old browsers and it's really easy to make things that are hard to reason about (defined in several places, used in calc()s, overridden in the cascade, etc). On a team that doesn't communicate or test well vars can be a source of pain.
richeyryan 4y ago
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 4y ago
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.
- deleted 4y ago
  [deleted]
- naasking 4y ago
  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.
- atsjie 4y ago
  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.
theteapot 4y ago
> I hate Tailwind with the passion of a million suns. How much passion does your standard sun contain?
- pwdisswordfish9 4y ago
  According to Wikipedia, it’s 15 megakelvins.
- FredPret 4y ago
  Enough passion for the feelings engendered by Macromedia Flash?
bluetidepro 4y ago
> 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 4y ago
  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"
  - anhner 4y ago
    > "Tailwind is for beginners" just sounds to me like "I don't like this thing because I'm too smart for it" More like "I don't like this thing because I don't understand it, so I blame it on juniors because I feel superior to them, so I must be right"
  - waboremo 4y ago
    Because Tailwind is often suggested as a way for novices to implement design without having to really learn CSS. Simultaneously, allows people who don't care at all for CSS or design to create something functional. Tailwind does not require knowing CSS. It'll get you around tailwind faster if you do know it, but you do not have to care about what Tailwind is really up to when adding "outline outline-2 p-4 outline-offset-2". This is a major reason why people pick it up in the first place, to ignore CSS as much as possible.
    - danielvaughn 4y ago
      Tailwind absolutely requires knowing CSS. You cannot effectively use `outline-2` without understanding what an outline is.
pupppet 4y ago
My best argument against it is whatever the learning curve, you're better served just spending that time learning to write CSS instead.
- super256 4y ago
  When you pick up tailwind, you will automatically learn vanilla CSS along the way.
  - Bilal_io 4y ago
    I like Tailwind, but I am not sure I'd recommend it to someone without prior experience and deep understanding of CSS. In my opinion, abstractions rarely teach us the underlying layers of a technology.
    - super256 4y ago
      > I like Tailwind, but I am not sure I'd recommend it to someone without prior experience and deep understanding of CSS. In my opinion, abstractions rarely teach us the underlying layers of a technology. I started with Tailwind and as I learned CSS along the way. Obviously people will look up stuff on MDN when they are stumbling on terms they didn't know about. The tailwind docs + tw-intellisense plugin [1] are pretty good, too. Especially since the extension shows the raw CSS behind the abstraction when you hover over a class name. [1] https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss https://marketplace.visualstudio.com/items?itemName=bradlc.v...
- CapnCrunchie 4y ago
  My understanding of CSS has gotten a lot better from using Tailwind.
  - postalrat 4y ago
    Have you reached a stage where you no longer feel its a good idea or are you sticking with it? I considered using it for a few projects but once I start I feel it too much work with no payoff.
lvl102 4y ago
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.
- postalrat 4y ago
  How does it not get in your way? If you ignore it?
  - dmitriid 4y ago
    It gives you a consistent design system with sensible defaults and easy-to-use (and rather memorable or easy to deduce) utility classes. Unlike the yet-another umpteenth bespoke `.card-header__buttons .card-header__button--secondary` that no one can remember and create an umpteenth+1 Tailwind works great when your site/app is a collection of components
    - atsjie 4y ago
      `.card-header__buttons` that example makes no sense unless you use global CSS/SASS, which very few projects do anymore. Component CSS/SCSS or CSS-in-JS are very common which resolve this scoping problem. So why bother with a DSL like Tailwind over Component CSS/SCSS for example?
      - dmitriid 4y ago
        How do you enforce consistency in CSS-in-JS? Paddings, margins, sizes, colors? Everywhere I've seen CSS-in-JS used, everywhere it's people busy writing bespoke styles in every file.
        postalrat 4y ago
        That's the same problem I see with tailwind. I prefer a global set of styles and more specific selectors to override styles where needed. It may not work well on projects with many teams but for the projects I typically work on it's fine.
karpour 4y ago
hk1337 4y ago
What would recommend for some sane CSS/SCSS defaults?
- hk1337 4y ago
  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?
  - terminal_d 4y ago
    This might be helpful. https://necolas.github.io/normalize.css/ https://necolas.github.io/normalize.css/ Design decisions, though, are ultimately up to your taste and judgement.
  - bdougherty 4y ago
    I copied this from a specific project, so there might be a couple things missing, but here is generally what I use https://gist.github.com/bdougherty/404b4ca33dfdbff48614b454f790684c https://gist.github.com/bdougherty/404b4ca33dfdbff48614b454f...
karaterobot 4y ago
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.
- sorahn 4y ago
  > 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).
- mind-blight 4y ago
  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
Kiro 4y ago
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.
- christophilus 4y ago
  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:
- hk1337 4y ago
  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?
troysk 4y ago
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.
rkangel 4y ago
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.
matthewmacleod 4y ago
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.
cactus2093 4y ago
> 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.
eiiot 4y ago
> 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 4y ago
  > 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 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.
  - eiiot 4y ago
    > If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice. I would say the documentation adequately responds to your complaints about re-usability then? Use a component, use the IDE, or use @apply. The notion about needing to change classes 1000 times for a small edit just isn't true (I've never had to do this w/ 2+ years of tailwind). > I think you're too narrow minded to accept any input so I won't bother. Making some sort of ad hominem attack about how I'm narrow minded is useless. I'd love to hear your input.
jmull 4y ago
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.
rndmize 4y ago
> 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.
kaba0 4y ago
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.
chrisweekly 4y ago
Your comment would have been radically better if you'd omitted the first three sentences.
b1n 4y ago
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 4y ago
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/ https://vanilla-extract.style/
pocketsand 4y ago
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.
dimmke 4y ago
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.
naasking 4y ago
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 4y ago
  Happen to have a blog post link handy? Would like to see this strategy in more detail. With something like Django if possible.
  - naasking 4y ago
    Never used Django, but I see lots of videos/talks on Youtube discussing the combination of Django+HTMX+Tailwind (and sometimes also Alpine.js). Looks like some of them use Tailwind classes inline, but I assume Django has a way to bind from a model, in which case you can declare global static models for standard styling, like text inputs, charts, tabs, etc. and have those accessible to views.
deleted 4y ago
[deleted]

onion2k 4y ago

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.

kypro 4y ago
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.
- 9dev 4y ago
  But p-4 is a variable: you can set the actual padding applied in the configuration file! It doesn’t have to mean 8px, but rather „standard amount of padding“. If you want to use „small amount of padding later on, you’ll use p-2 - whatever that means in your app. That solves the exact problem you and OP complain about, in a neat, configurable, safely replaceable way. Tailwind allows you to separate design intent from implementation values.
  - waboremo 4y ago
    Vanilla CSS also allows this, without any real effort either. Tailwind's power is in its defaults, as soon as you want to start tinkering, you were much better suited sticking to vanilla CSS.
    - 9dev 4y ago
      I didn’t dispute that. I just refuted parents point here.
- onion2k 4y ago
  Variables would be the obvious answer here. Variables are very cool and super powerful, but they fall down if you need to support old browsers and it's really easy to make things that are hard to reason about (defined in several places, used in calc()s, overridden in the cascade, etc). On a team that doesn't communicate or test well vars can be a source of pain.

richeyryan 4y ago

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 4y ago

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.

deleted 4y ago
[deleted]
naasking 4y ago
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.
atsjie 4y ago
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.

theteapot 4y ago

> I hate Tailwind with the passion of a million suns. How much passion does your standard sun contain?

pwdisswordfish9 4y ago
According to Wikipedia, it’s 15 megakelvins.
FredPret 4y ago
Enough passion for the feelings engendered by Macromedia Flash?

bluetidepro 4y ago

> 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 4y ago
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"
- anhner 4y ago
  > "Tailwind is for beginners" just sounds to me like "I don't like this thing because I'm too smart for it" More like "I don't like this thing because I don't understand it, so I blame it on juniors because I feel superior to them, so I must be right"
- waboremo 4y ago
  Because Tailwind is often suggested as a way for novices to implement design without having to really learn CSS. Simultaneously, allows people who don't care at all for CSS or design to create something functional. Tailwind does not require knowing CSS. It'll get you around tailwind faster if you do know it, but you do not have to care about what Tailwind is really up to when adding "outline outline-2 p-4 outline-offset-2". This is a major reason why people pick it up in the first place, to ignore CSS as much as possible.
  - danielvaughn 4y ago
    Tailwind absolutely requires knowing CSS. You cannot effectively use `outline-2` without understanding what an outline is.

pupppet 4y ago

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

super256 4y ago
When you pick up tailwind, you will automatically learn vanilla CSS along the way.
- Bilal_io 4y ago
  I like Tailwind, but I am not sure I'd recommend it to someone without prior experience and deep understanding of CSS. In my opinion, abstractions rarely teach us the underlying layers of a technology.
  - super256 4y ago
    > I like Tailwind, but I am not sure I'd recommend it to someone without prior experience and deep understanding of CSS. In my opinion, abstractions rarely teach us the underlying layers of a technology. I started with Tailwind and as I learned CSS along the way. Obviously people will look up stuff on MDN when they are stumbling on terms they didn't know about. The tailwind docs + tw-intellisense plugin [1] are pretty good, too. Especially since the extension shows the raw CSS behind the abstraction when you hover over a class name. [1] https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss https://marketplace.visualstudio.com/items?itemName=bradlc.v...
CapnCrunchie 4y ago
My understanding of CSS has gotten a lot better from using Tailwind.
- postalrat 4y ago
  Have you reached a stage where you no longer feel its a good idea or are you sticking with it? I considered using it for a few projects but once I start I feel it too much work with no payoff.

lvl102 4y ago

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.

postalrat 4y ago
How does it not get in your way? If you ignore it?
- dmitriid 4y ago
  It gives you a consistent design system with sensible defaults and easy-to-use (and rather memorable or easy to deduce) utility classes. Unlike the yet-another umpteenth bespoke `.card-header__buttons .card-header__button--secondary` that no one can remember and create an umpteenth+1 Tailwind works great when your site/app is a collection of components
  - atsjie 4y ago
    `.card-header__buttons` that example makes no sense unless you use global CSS/SASS, which very few projects do anymore. Component CSS/SCSS or CSS-in-JS are very common which resolve this scoping problem. So why bother with a DSL like Tailwind over Component CSS/SCSS for example?
    - dmitriid 4y ago
      How do you enforce consistency in CSS-in-JS? Paddings, margins, sizes, colors? Everywhere I've seen CSS-in-JS used, everywhere it's people busy writing bespoke styles in every file.
      - postalrat 4y ago
        That's the same problem I see with tailwind. I prefer a global set of styles and more specific selectors to override styles where needed. It may not work well on projects with many teams but for the projects I typically work on it's fine.

karpour 4y ago

hk1337 4y ago

What would recommend for some sane CSS/SCSS defaults?

hk1337 4y ago
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?
- terminal_d 4y ago
  This might be helpful. https://necolas.github.io/normalize.css/ https://necolas.github.io/normalize.css/ Design decisions, though, are ultimately up to your taste and judgement.
- bdougherty 4y ago
  I copied this from a specific project, so there might be a couple things missing, but here is generally what I use https://gist.github.com/bdougherty/404b4ca33dfdbff48614b454f790684c https://gist.github.com/bdougherty/404b4ca33dfdbff48614b454f...

karaterobot 4y ago

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.

sorahn 4y ago
> 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).
mind-blight 4y ago
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

Kiro 4y ago

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.

christophilus 4y ago
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:
hk1337 4y ago
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?

troysk 4y ago

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.

rkangel 4y ago

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.

matthewmacleod 4y ago

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.

cactus2093 4y ago

> 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.

eiiot 4y ago

> 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 4y ago
> 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 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.
- eiiot 4y ago
  > If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice. I would say the documentation adequately responds to your complaints about re-usability then? Use a component, use the IDE, or use @apply. The notion about needing to change classes 1000 times for a small edit just isn't true (I've never had to do this w/ 2+ years of tailwind). > I think you're too narrow minded to accept any input so I won't bother. Making some sort of ad hominem attack about how I'm narrow minded is useless. I'd love to hear your input.

jmull 4y ago

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.

rndmize 4y ago

> 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.

kaba0 4y ago

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.

chrisweekly 4y ago

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

b1n 4y ago

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 4y ago

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/ https://vanilla-extract.style/

pocketsand 4y ago

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.

dimmke 4y ago

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.

naasking 4y ago

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 4y ago
Happen to have a blog post link handy? Would like to see this strategy in more detail. With something like Django if possible.
- naasking 4y ago
  Never used Django, but I see lots of videos/talks on Youtube discussing the combination of Django+HTMX+Tailwind (and sometimes also Alpine.js). Looks like some of them use Tailwind classes inline, but I assume Django has a way to bind from a model, in which case you can declare global static models for standard styling, like text inputs, charts, tabs, etc. and have those accessible to views.

deleted 4y ago

[deleted]