Hacker News Reader

Comment by 734129837261 | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

I didn’t dispute that. I just refuted parents point here.

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.

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.

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.

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

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

Agreed. I think he's completely misidentified why CSS-in-JS became a thing.

I've done a lot of thinking about this - like "How would we adopt what we have done in frameworks into web standards"? And the closest I have come up with is Svelte.

In Svelte your file is a component. It can have a <script> tag which defines state that can be passed to it or any other arbitrary javascript. You can have a <style> tag which scopes specifically to that component. And the rest is just regular HTML markup with the ability to do light interpolation for dynamic values.

That's how it should be, in my opinion. That's what we should be moving towards as an industry. I think CSS-in-JS was a side effect of JSX being in JavaScript. Hopefully we are moving away from that trend now.

I cannot agree with this comment any more. Every time I read any one of these Tailwind threads, I am yelling in my head "SVELTE!!!!" the whole time. Going against the current of the platform is a recipe for disaster every time, and Svelte is one of the few frameworks that is actually trying to go _with_ the current.

I wrote that because the benefit most people who liked styled-components told me they appreciated was that they didn't have to think about inheritance. Everything is encapsulated in the component. This, to me, is equivalent to saying "I think the cascading part of CSS is either a mistake, or too complicated to maintain in practice, so I am going to eliminate it."

> This, to me, is equivalent to saying "I think the cascading part of CSS is either a mistake, or too complicated to maintain in practice, so I am going to eliminate it."

I agree both with your interpretation, and with the sentiment. I think, in many contexts, using the Cascading part of CSS is a mistake. It's great for low-level design system kinds of work (e.g. setting matching text and BG color, then override font size or decoration later). But, it's pretty problematic when you start styling specific components in a web app. (This is less of an issue with static documents).

If we're using SASS instead of a css-in-js, we end up doing things like:

``` .my-custom-hero { h1 { // override necessary styles } } ```

That's essentially the same encapsulation. It's just hidden in a one-off class in the CSS rather than embedded with the HTML - which makes it even less legible. It also has a dependency on the root-level `h1` styles. If someone change those, they inadvertently change the hero's styles.

We could get around that by having a `.my-custom-hero .my-custom-hero-title`. But, that's essentially a worse version of css-in-js encapsulation: I have to come up with names for everything, and my component's internals are split across multiple files.

Whether you like it or not, the cascading part of cascading style sheets is an integral part of the web platform, and one is better off in the long run swimming with the current of the platform rather than against it.

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

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"

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

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.

Tailwind absolutely requires knowing CSS. You cannot effectively use `outline-2` without understanding what an outline is.

Millions of people know what an 'outline' is without knowing what CSS is. You might need a better example than 'outline'.

They can't explain the difference between an outline and a border though, and especially can't explain when to use which. If you try to use Tailwind without understanding that, you're gonna have a Bad Time™.

> Because Tailwind is often suggested as a way for novices to implement design without having to really learn CSS

Where are do you so frequently see that being suggested? I would never suggest that and I've never seen anyone say something like that before.

Tailwind is not an alternative to CSS, it's a way of writing CSS.

Being bad at CSS is certainly why I love it. But that doesn't mean it's not a great tool for experienced frontend developers as well.

But almost every Tailwind shortcut translates to one line of CSS. So you need to know CSS, for example you understand words 'padding' and 'margin'. I did not know these words mean before learning CSS.

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.

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.

I've been writing FE for 15 years and I'm in love with Tailwind. I never have to worry about naming, which in and of itself saves me a mountain of time. I had no idea just how much effort I spent on it until I stopped. Also, what I love about Tailwind is that it isn't an abstraction - the parent comment makes no sense because you can't use Tailwind without understanding CSS. But for those who do understand, it makes you so much more efficient, especially with a plugin like Tailwind Intellisense.

Your HTML will be uglier and it will be more difficult to look at the elements panel to find the element you're looking for. Both of those things are super minor for me, and have almost no impact on my day-to-day.

Don't follow the hype and trust your own experiences and tooling. Tailwind can be good, but I get the sense that many commenters (not in this thread, however) may be paid actors in order to boost its mindshare.

This is so frustrating to read over and over. Tailwind uses PostCSS. You can literally wrap a bunch of utilities inside a semantic class name.

Or, if you're using containers/writing components you can literally do something like this: https://pastebin.com/qkdzGWNT

But that a { could just as easily be "tag"

Personally, I've always found BEM to be tedious and the sort of "roll your own" class names just doesn't scale. This approach scales. This is what we should be moving towards as an industry.

> This is so frustrating to read over and over. Tailwind uses PostCSS. You can literally wrap a bunch of utilities inside a semantic class name.

If it's being asked repeatedly, it should probably be addressed somewhere. I see no mention of it in the tutorial or any of the amazing starter videos I've seen. I also have never used PostCSS directly before, so that's not an obvious solution. I appreciate the example you shared. I've asked (the OP in particular) in good faith, so I'm sorry that the question frustrated you.

> Personally, I've always found BEM to be tedious and the sort of "roll your own" class names just doesn't scale. This approach scales. This is what we should be moving towards as an industry.

Can you please elaborate on this? We've had well-functioning applications that predate Tailwind or CSS in JSS, so I'm not sure what doesn't scale. Descriptive names might get messy if you jam everything into in a single stylesheet, but using the cascading part works pretty well. If we're going to say "no, actually we were completely wrong when we said class names based on styles like 'red', 'big', and '2spaces' were bad", I'd like to understand what fundamentally changed. If it's just a case of convenience, that's fine. But, what about this scales better? How does this approach improve maintenance?

Your PostCSS example where you compose rules looks like a good approach, but I don't see that widely in use. Instead, I see the same rules repeated across elements in a document. That's the style the Tailwind docs use, so I'm operating under the notion that this is the prevailing way to write frontend code with Tailwind. While I can see that as an improvement over inline styles by ensuring consistent spacing definitions and such, that was never the recommended approach anyway. The style used in the Tailwind docs strikes me as being more problematic for ensuring consistency across pages or an app, which I see as hampering scalability.

Anyway, I'm trying to better understand why and how this shift is better. The only clear answer I've had thus far is that it's faster to get started because you get nice styles out of the box without having to adopt something like Bootstrap. That makes sense to me for small projects. At least I can see why someone would make that trade-off. I'm less clear on the long-term maintenance aspect and how utility classes help that.

Fair enough. I've realized I am currently using Tailwind in a way that is not the default and maybe a lot of people don't know about it. I think I will write a blog post about it.

Also, I think I am wrong. It's possible to use Tailwind without implementing a build step like PostCSS, which would necessitate using it much like the documentation describes.

>We've had well-functioning applications that predate Tailwind or CSS in JSS, so I'm not sure what doesn't scale.

CSS has fallen victim to the same "cult of semantics" that HTML has, and it's disingenuous bullshit just like it is in HTML (mostly).

Yes, if you have someone who really cares and writes great CSS they will have everything broken out into custom variables and well designed and named classes. You still have the problem of how you scale that, right? After all, if you have a .card that is formatted one way on one page but laid out differently on another, you have to think up a different class name or refactor.

Enter BEM. Block, element, modifier. A consistent naming system for your large application. That is both subjective, requires a lot of extra mental bandwidth in a time when you're lucky if half the "front-end developers" you're working with know more than the basics of CSS to begin with.

I have seen some truly tortuous HTML that uses BEM classnames. It was awful.

So when I say it doesn't scale, it's that most large codebases end up with !important everywhere and z-index:9999999 etc...

So throw it out completely. Utility classes make sense when you accept that you are probably styling a component and that markup will be inserted everywhere the component is. You never have to think about what your class name should be, and if it makes sense, or if it conflicts with other scopes.

Yes, an HTML element with 15 classes is not ideal.

The example I posted would hopefully be the logical end (and is if you're using Svelte with PostCSS configured) - where we're no longer writing html documents full of elements and then a stylesheet styling them. Each discrete UI element has one document, markup, state and styling are tightly coupled, and it can be reused many times.

It gets rid of nesting being very important, it gets rid of having to write verbose media queries for responsive. It makes changing things really fast.

The part about Tailwind providing sensible defaults in terms of sizing, spacing etc... is just icing on the cake. The problem that Bootstrap had is that it tried to do too much. It came about in an era when doing layout in CSS was really hard. So it rolls its own stuff like modals, dropdown menus, grid etc... it also takes it upon itself to style actual HTML elements, which to me is a very poor choice. Including bootstrap will get you default styles for headings etc... but I believe in Tailwind it's all done through utility classes.

Tailwind doesn't do that. The focus is on removing semantics from styling. Look at the API surface: https://tailwindcss.com/docs/

There's a "Components" link, but that's to a paid resource showing common UI patterns built with Tailwind.

Also, I did look at the docs and there is an entire page dedicated to this subject that you can read and it does mention @apply.

https://tailwindcss.com/docs/reusing-styles#extracting-class...

Thanks. I did overlook that. Although, the docs are a bit foreboding.

"Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse."

Then it lists a bunch of reasons that seem to just be the author's preferences on things like naming and workflow productivity. I guess I don't think naming things is that hard. I generally need a name of some sort anyway so I can interact with the thing from JS. I haven't seen anyone argue not to use React or Web Components because naming a component is hard. I wonder if it's just a granularity thing. I tend to give a class name to a logical entity and then use ancestry selectors for nested tags, with SCSS mixins to avoid duplication.

I agree that some of it is preference, but the main point he is making is that the number of utility classes doesn't matter if you're using a framework and styling a component. Yeah, it's ugly markup but so what?

With that said, I think it's reasonable to roll some things up into general classes. They remain very easy to change.

>I haven't seen anyone argue not to use React or Web Components because naming a component is hard.

I think the whole point is that that UI element, or "interface", or "component" is the thing that should have a name. That entity doesn't need to have a unique CSS classname.

Got it. So this would be more of a hybrid approach and clears up that question on naming granularity. Give the "component" a logical name and use the utility classes for the component's entities. That makes a lot more sense to me. I didn't realize those child entities were the things people were giving names to. CSS has fairly rich ancestry rules, so I just assumed people use them.

Thanks for taking the time to clarify that for me. It does indeed change my perception on utility classes.

I still think you're misunderstanding. It sounds like you think that the component has a class and everything flows from that. Like .component-name a {}

The point is that HTML elements don't need to have semantic class names at all. So even the top most element in the component would still use utility classes.

I didn't think naming things was that hard, until I got a chance to try building a project without having to name things. I'll never go back.

Semantically named classes is a lot of effort to come up with, and don't really help much. One of the big selling points is that you can quickly style things without having to name every HTML element.

Thanks. I've commented on this elsewhere, but I think there's probably a mismatch in my thinking on the granularity of naming. I don't literally name every single element I'm styling. I agree that would lead to some very contrived names. I've understood semantic naming to apply to what, for lack of a better term, I'd call a component and then use ancestry rules to style within that "component". If you need to customize it, you can use the cascading part of CSS or use a pre-processor like SCSS to mix in and override things. I've found that leads to easily identifiable rules.

Of course, the trade-off is if you completely change the structure of that "component" you'll need to update any ancestry rules. But on the naming front, I'd need to come up with an identifier or logical class name to find the element in JS anyway, absent something like React that sort of controls the world.

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

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.

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

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

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

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.

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.

> That's the same problem I see with tailwind.

The thing with Tailwinf is that it already has a decent design syste encoded in its utility classes. It's very easy to slap a p-2 for a standardized padding than trying to remember what it was when you write the next component with `{ padding: 2 2 2 2 }`

> I prefer a global set of styles and more specific selectors to override styles where needed.

That's kinda what I mean. In all projects I've seen you have a global stylesheet with a bunch of classes that no one remembers, and hundreds of one-ofs in every component either reimplementing stuff from scratch or serving as an `!important` of sorts

> How do you enforce consistency in CSS-in-JS? Paddings, margins, sizes, colors? JavaScript variables, css variables? Both can be used. It's pretty trivial tbh.

By having a style guide with variants, StitchesJS pioneered this but there are others like Vanilla-Extract. With TypeScript, you can then enforce that only a certain variant can be used with a certain component at compile time, basically making sure that your design style guide gets mapped 1:1 to your code.

https://stitches.dev/

Hm. I see the same CSS-in-JS with a sprinkle of string interpolation for some variables :)

I may run into the same issues as the other CSS-in-JS solutions (I only encountered stitch once, and not for a long period of time)

Unlike other CSS-in-JS though, the way it's made, via object properties, enforces compliance to the design system. In things like styled-components, it doesn't.

Doubly so when using TypeScript, as with Vanilla-Extract: https://vanilla-extract.style

> the way it's made, via object properties, enforces compliance to the design system.

The link literally has this:

``` export const className = style({ display: 'flex', flexDirection: 'column', selectors: { '&:nth-child(2n)': { background: 'aliceblue' } }, '@media': { 'screen and (min-width: 768px)': { flexDirection: 'row' } } }); ```

Which is indistinguishable from any other CSS-in-JS which has hundreds of these one-off things scattered everywhere. With a theme somewhere exposing another hundred or so variables of varing quality. And all these solutions basically converge on Tailwind (or other utility-first CSS approaches):

``` export const hero = style({ backgroundColor: vars.color.brandd, color: vars.color.white, padding: vars.space.large }); ```

is nothing more than `bg-brand color-white p-4`

But TypeScript support is definitely nice.

Sorry, could you reformat your code? I can't read this well.

Sorry, I keep forgetting that HN is weird with line breaks

Re-typing/re-quoting:

--------

The link literally has this:

    export const className = style({
      display: 'flex',
      flexDirection: 'column',
      selectors: {
        '&:nth-child(2n)': {
          background: 'aliceblue'
        }
      },
      '@media': {
        'screen and (min-width: 768px)': {
          flexDirection: 'row'
        }
      }
    });

    export const hero = style({
      backgroundColor: vars.color.brandd,
      color: vars.color.white,
      padding: vars.space.large
    });

is nothing more than `bg-brand color-white p-4`

But TypeScript support is definitely nice.

----

This video from Stitches shows their API well, which VE copied with their Recipes plugin, code example below (timestamped to 31:07 in case the link doesn't work) [0].

    /// Define variants for a specific component, such as a button
    export const button = recipe({
      base: {
        borderRadius: 6
      },
    
      variants: {
        color: {
          neutral: { background: 'whitesmoke' },
          brand: { background: 'blueviolet' },
          accent: { background: 'slateblue' }
        },
        size: {
          small: { padding: 12 },
          medium: { padding: 16 },
          large: { padding: 24 }
        },
        rounded: {
          true: { borderRadius: 999 }
        }
      },
    
      // Applied when multiple variants are set at once
      compoundVariants: [
        {
          variants: {
            color: 'neutral',
            size: 'large'
          },
          style: {
            background: 'ghostwhite'
          }
        }
      ],
    
      defaultVariants: {
        color: 'accent',
        size: 'medium'
      }
    });

    /// Use in code
    <button className={
      button({
        color: 'accent',
        size: 'large',
        rounded: true
      })
    }>
      Hello world
    </button>

Basically, unlike other CSS-in-JS libraries, you can encode your design system into something called variants, then you use them by calling the function `button()` to generate a class name.

Notice how `button()` takes in certain properties and only those properties with their corresponding values (enforced by TypeScript). If you try to put in `button({ color2: 'testColor', ...})`, TS won't compile.

In this way, you can take the design team's ButtonSmall, ButtonLarge, NeutralButtonLarge etc and codify them into TypeScript such that you literally can't make a mistake. You simply can't do that in Tailwind, unless you use some outside plugin I assume.

(Note that VE also has a Tailwind-like atomic CSS API called Sprinkles, but since I don't like Tailwind I don't use this either).

[0] https://youtu.be/Gw28VgyKGkw?t=1867

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.

This is probably the main thing that puts people in one camp or the other.

Before Tailwind came along I very often found myself just wanting to put some inline styling in various places. It's so much easier to just add some CSS to an element than having to think of a class name, think of where the best place would be to put the class, etc.

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

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

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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/

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

How much passion does your standard sun contain?

According to Wikipedia, it’s 15 megakelvins.

Enough passion for the feelings engendered by Macromedia Flash?

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.

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.

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:

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?

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

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.

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

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

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

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

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.

Same here. The CSS that each Tailwind class corresponds to is very visible in the documentation itself.

This has been my experience as well. Tailwind is a good pair of support wheels, but it gets annoying after a while, and is difficult to maintain long-term.

What make it difficult to main long term for you?

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.

I'd be very surprised if there are many devs with a deep understanding of CSS using Tailwind.

Well... you can bumble through using tailwind without understanding it much in the same way you can bumble through using CSS without understanding it much.

There are plenty of people bumbling through with both.

But understanding the CSS is needed to use it reasonably well.

I'm sorry but this is just a crazy thing to say. You cannot use Tailwind without understanding CSS.

Take the example `block`. Ok so a junior FE dev is supposed to use this class without understanding CSS? How?! It just maps to `display: block;`. It hides literally none of the complexity.

>It hides literally none of the complexity.

If it didn't hide any of complexity you'd be writing CSS.

Nope, it saves me (a) keystrokes and (b) design effort. The restricted subset of color options, for example, lets me use a predictable color system out of the box without having to think about it. It's not about removing "complexity" in the sense of understanding how CSS works.

With a stylesheet you have the styles in one place, with Tailwind you repeat it on every element. Yes components and copy/paste are a thing but I'd be very surprised if you're having to manage less style code with Tailwind. As for design effort, setup a few primary/secondary accent colors as global variables.

Not exactly - with Tailwind you aren't repeating the design decision, only the scalar value. So `border-2` might mean a border width of 4px or 6px or whatever, but that's the design decision that is encapsulated within the theme configuration.

I don't agree with the parent poster, but I would say that there is a large portion of frontend devs that "don't understand css" at a very deep level. For every 1 that does there are a good 9 or 10 that just get enough to get by.

That said -- you need to know the average amount of CSS to be successful using tailwind.

I'll give you an example of one:

Adam Wathan, the creator of Tailwind

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

What would recommend for some sane CSS/SCSS defaults?

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?

This might be helpful.

https://necolas.github.io/normalize.css/

Design decisions, though, are ultimately up to your taste and judgement.

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/404b4ca33dfdbff48614b454f...

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.

Reply on news.ycombinator.com