So basically the idea of Tailwind is to move back into inilne css? Sure, the syntaxis is different but the concept is the same. If tomorrow I want to change the color of all the buttons in my app I need to go to each HTML and update them.

The missing bit of context here is that you use components to create re-usable abstractions.

If I want to change the color of my buttons, I go change the "inline CSS" of the Button component I am using everywhere, and it changes everywhere.

On the other if you have used something like Svelte or Vue, then there would not be need for "inline CSS".

I would be interested in hearing more. In my understanding, these tools aren’t inherently contradictory, though I do see some folks agreeing with you.

I think they mean that because Svelte lets you put a style tag in a component and the styles are automatically scoped to that component, you don’t need Tailwind.

https://svelte.dev/examples/styling

I’d say that goes halfway toward solving the problem Tailwind solves and could well be enough for most people. It’s nice not to go to a different file, and it’s nice to get scoping. But you still have to come up with class names, and you still have to mentally match up what classes go where.

Nobody said that Tailwind is something super special and there's only one way to do this. I find it nicer than hand-writing global classes. YMMV.

My point is just that "If I want five buttons to change, I have to go find five places to edit it" isn't the reality of working with the tool in its intended way.

The idea is similar, but a component contains markup and logic on top of the styles.

The approach Tailwind takes is that since the component is named and contained, its elements don't have to be named explicitly. And while we could then use inline CSS, it has some limitations so utility classes are a more powerful tool.

No, literal React (or Vue or Svelte) Components. Not like making global classes.

Harder to use and maintain then tailwind.

>If tomorrow I want to change the color of all the buttons in my app I need to go to each HTML and update them.

If you find yourself repeating a certain combination of classnames over and over, you should refactor to make that a variable and use it in all the places where the repetition is. You might ask how is this different from CSS if these variables containing inline css are just classnames under another name? I would respond that they are basically the same thing, but Tailwind excels in the case where you need a style "just for this one spot" because you don't have to create a classname and edit two different files (html and css) to achieve the effect.

> Tailwind excels in the case where you need a style "just for this one spot" because you don't have to create a classname and edit two different files (html and css) to achieve the effect.

Inline style attributes and <style> blocks already solve this...

I suspect most of the mania around CSS frameworks is that people don't grok that you don't HAVE to put everything in one big external .css file -- there is a spectrum of ways to declare CSS and with modern browser dev tools it becomes easy to understand where each rule is coming from.

> Inline style attributes and <style> blocks already solve this...

Sure. The point of tailwind is to make this nicer, not to fully replace it.

I find the naming scheme and helpers they provide to make writing CSS a lot easier. Mind you, I would never claim to be a CSS expert in the first place. But Tailwind isn't trying to be something different, it's trying to make something easier and better.

I like vim too. I feel like there's a vague similarity here.

I would argue that Tailwind's job is to basically fully replace everything if done idealistically. You want the ability to focus on a single component without thinking that there's CSS somewhere else.

I do agree that it's best practice to always use only the tailwind classes, I guess what I mean is, it's not like it makes it impossible to use just CSS. It is, in my mind, a nicer way to write CSS, that brings some of its own advantages, but it's not like, fancy magic. It is CSS, fundamentally, not something else.

It seems so, also people using it in my team are agaisnt creating ids or unique classes for elements, so when I am asked to debug some issue you can't just inspect the element and see it's id and class to find it easy to locate teh file where it was created, you have to search for some text that is around it and hope it is unique enough that you can guess the correct file from the list the search for that text returns.

Some stuff makes sense like the "flex" classes but IMO the margins, paddings, text sizes, colors is extremism.

Tailwind is more a way to easily apply styles in websites built using one of the popular app and/or component frameworks. If you have many different buttons you’d create a Button component and the framework would do the work of „copying and pasting“ that component across your site.

The benefit of Tailwind is that it standardizes styles. Even in a small button component, I’d have to create classes to attach my styles to. New team members would then have to figure out how and where something is defined.

With Tailwind, any developer familiar with it can search for „bg-blue-500“ and turn it into „bg-red-500“.

So it’s mainly a solution for large websites and teams. On a small, handmade website, well thought out classes in a central stylesheet is definitely the way to go.

I’m my opinion, the benefits of Tailwind are debatable and I really don’t like the readability of it. Any complex component will have a need for classes that are assigned depending on other variables and conditions so the naming problem doesn’t go away either. So in the end I favor component scoped CSS where my HTML is concise, with a few classes and conditions and then a style tag below.

I wonder if there are Tailwind die-hards who are also super comfortable using modern vanilla CSS?

I understand Tailwind works and gets the job done and is probably more accessible than learning CSS, but do CSS experts also prefer it?

Working with Tailwind made me better at vanilla CSS. And it's a virtuous cycle: the better I get at vanilla CSS the more I've come to appreciate a) how composable Tailwind is, and b) how perfectly Tailwind dovetails into component-based application UIs.

Sample size of 1 here.

I lived through every CSS fad for writing "maintainable" css, and have settled on Tailwind. It doesn't limit you, you can always add normal old css files to your project if you need / want to.

But what it means is I don't end up with a `utilities.scss` of `.flex` `.block` etc etc etc, which you always do on any project. I get a full catalogue of utility classes that only get included in the generated css if I use them in my project, I don't have to think about class names, and I don't have to open a separate css file.

The only con is sometimes an absolutely ridiculous amount of utility classes on an element, but frankly scarlet...

Me! I like writing CSS and have been doing so since it was introduced. Tailwind has been, by a large margin, my favourite “framework.” In fact it’s the only one I’ve liked. I used bootstrap a bunch but never loved it.

The meme of Tailwind is only for n00bs, look at me hand-crafting selectors is bullshit. Very similar to the clowns who preferred document.createElement over JSX for SPAs back in the day.

Tailwind can be a very productive tool that feels odd at first and remains odd for elements like input fields but absolutely has its place. It comes with a fraction of the foot guns typically associated with CSS for the tiny cost of looking a bit silly at first. And this is coming from someone who loves (near) class-less CSS frameworks.

No, you should define semantic names for your colors and then modify the tailwind.config.js build config to indicate the actual color.

That's rarely done in practice. Even Tailwind's own site hardcodes colors.

We do exactly that. And if you're not thinking semantically with Tailwind, you probably aren't thinking semantically with css / sass variables anyway, as it's the exact same thing.

No, the idea of tailwind is to provide a natural bridge between inline styling and class based styling that you can hook into at any point. You can compose styles and use those composed styles elsewhere if that is your best pattern, it's really flexible.

This is why I love imba.io so much, it has everything in one file.

js, html, css > all within the proper component context in a reasonable OO form (react fx can fx right off)

And, Imba global css classes are importable to other tags at the top level, no need to reimport, just .class-me

Not at all, Tailwind lets you define your own classes - so you can have text-primary text-secondary, just like you would with sass or css variables (in fact you can use css variables to generate your tailwind classes).

My gripe with this argument is that if you value readability, you end up defining your own classes, and if you end up defining your own classes, you don't need Tailwind – at this point, it's just a build layer with its own variables.

Not really. OP suggested to have classes for color palette which is completely reasonable. The tailwind role is to provide easy to use, read and maintain classes. It is not to manage color palette of the project.

You can use SASS/SCSS to build anything you'd do with regular CSS. For example:

.color-primary { color: white; }

.some-text { @apply color-primary; }

we have css variables now, we don't even need to do that

This is exactly how tailwind works under the hood. It creates css vars for all of your configurations, so you can either use the class names, or perform calculations from the vars

I know, I was just demonstrating a feature of tailwind related to OP's remark

Another post about Tailwind, another person claiming it's exactly equal to inline CSS eye roll. This one uses a "back to" qualifier, implying a historical revision that inline styles were ever the sanctioned way! Good lord...

There is plenty of info out there about why Tailwind, or rather utility-first in general, works in many situations. The "classic" way is still also appropriate. I use both depending on the project, though I really like Tailwind and is by far my favourite method most of the time. I say this as someone in their 40s who has been enjoying writing CSS since it was first introduced in the late 90s (yep, guilty of Stockholm Syndrome here).

See it as the same issue of orm's vs SQL.

Tailwind is "SQL" for CSS

For anyone reading this since its pretty high, it's one of those cases of really high HN bias, that actually got to me.

I'm not blaming OP, the question seems innocent enough, but I had this bias and some others myself until I used Tailwind for an actual project and have never looked back, and most of the criticism that appears in HN is just misunderstood concepts and harsh sounding soundbites.

I distrust HN's general sentiment on stuff more (if there is such a thing but you know what I mean), I check for myself.

Regarding tailwind specifically, it's the modern way of "just css" which goes amazingly well with having the component abstraction level.

You don't abstract your css, you keep it all in base level, you abstract components, in this particular case you would go to your button component and change all of the application's button at once.

Thanks for explaining, that makes sense. And yes, my question was innocent. I am not a frontend dev, I used to do some CSS and vanilla JS back in the day. Thanks for taking the time to explain it to me!

Creating a component out of everything always sounds good in theory but falls apart in practice. There's always that oddball element that doesn't quite work as a component, and then you end up with a component and a bunch of the outliers that you need to remember to manually update.

I wanted to read this, but seeing that godawful AI generated filler picture made me reconsider.

I clicked thinking "It can't possibly be that bad" but wow it's really bad and it's taking up the entire screen.

I had the same reaction, it gives you the feeling that the article itself is also AI

My immediate next question is how much of the article is AI generated filler.

article was nice to skim. I learned a few new things

I love the AI image. It's better than barren text. They just need to fix the garbled text, though honestly that's starting to become a fun artistic artifact.

I disagree about it being better than just barren text. I don’t get the need to use a picture, even when there’s nothing to show. It’s just useless filler, remove it and move on

Using Tailwind daily, I know most of these but the `size-*` is new to me, will use that a lot now!

One of my favorite tricks is `gap-x-*` or `gap-*`, it's great for grid or flex components to space their children components, and the first and last element don't get spacing added around them so everything lines up nice.

As another commenter noted, the AI generated image was a bit weird to see.

Also it should be "Combining font-size and line-height"

Call me a curmudgeon, but I am still not a fan of Tailwind.

I know a lot of newer engineers that believe it’s a perfectly acceptable alternative to learning CSS, to which I always respond: using Tailwind does not absolve you from having to learn CSS.

There are also a lot of comments in this thread claiming that the “right” way to use Tailwind is to create composite classes using its utility classes, but I have rarely seen anyone do this in practice.

Instead, the inline classes pollute the markup to the point of becoming extraordinarily difficult to read, and unless you make a concerted effort to e.g. bury as much of that garbage markup in reusable components as possible, it remains a persistent eyesore.

People don't do that because it's not the right way and is explicitly discouraged by the docs: "While it’s highly recommended that you create proper template partials for more complex components, you can use Tailwind’s @apply directive to extract repeated utility patterns to custom CSS classes when a template partial feels heavy-handed."

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

Using Tailwind is having an effect on how I build components.

I've really fallen in love with Tailwind and atomic design.

And I've discovered that Atomic design can be more than just for styles, but for behavior and content generation too.

Here's a snippet of an annotation-driven version of Razor that I'm working on. This snippet composes a table of weather data using atomic annotations that add styles and behavior.

```

@@<Spacing MarginTop="@Theme.Spacing.Large" />

@@<Placeholder Show="@(!(forecasts?.Any()??false))" Variant="@Placeholder.Skeleton" />

@@<DataAnnotations All="@true" />

@@<PlQuickGrid />

<QuickGrid Items="@forecasts">

    <PropertyColumn Property="@(c => c.Date)" />

    <PropertyColumn Property="@(c => c.TemperatureC)" />

    <PropertyColumn Property="@(c => c.TemperatureF)" />

    <PropertyColumn Property="@(c => c.Summary)" />

</QuickGrid>

```

Here's what the annotations do...

@@<Spacing> - adds TW class style equivalent to 'spacing-[--my-spacing-token-l]'

@@<Placeholder> - displays a skeleton placeholder, instead of the table, when loading data

@@<DataAnnotations> - extends the QuickGrid with formatting and label metadata found on forecast Type

@@<PlQuickGrid> - Applies custom component styles to a Blazor Quickgrid

The first three annotations are reusable across a wide variety of components.

Tailwind and atomic design have really taken hold of me, I'm gonna go all the way down that rabbit hole :-).

I love how easy it is to add a PWA selector:

https://github.com/tailwindlabs/tailwindcss/discussions/6755

The `peer`-modifier has a very significant and unfortunate limitation which prevents it from being useful for things like styling `<label>` elements that precede input controls, which is that it can only target a previous sibling above it and not the next sibling below, which is often the case in forms and other components. This is a limitation with CSS and not Tailwind fwiw.

How is that a limitation of CSS? I would think the previous sibling would historically be harder (but doable with :has), since next sibling is the way CSS has always worked.

  .foo:has(+ .foo)

vs

  .foo + .foo

I'm still not following the limitation. You can use ~ in place of + in my example and it'll work for subsequent siblings too, not just for next sibling.

Can you share a snippet or link to a repl showing how I can use `peer-` to make the label below have a gray text color when the input sibling is disabled?

``` <label for="email">Email</label> <input disabled id="email" type="email" /> ```

Ah, I see. May simply be the case then that `:has()` is relatively new and it wasn't possible prior to it's general availability as recent as Dec 2023.

I don't use Tailwind but this is easy with CSS:

  label:has(+ input:disabled) {
    color: gray;
  }

Not sure why Tailwind couldn't do this.

If that's the case in some circumstances should be able to work around that by wrapping the field+label in a flex container and rendering them in reverse.

That sounds like most solutions I have to come up with when using CSS for any kind of non-trivial UI :)

That is like a surprising limitation! Any idea why?

One day I was asked to take on a web development assignment. The aim was to make the website delivered by a guy look more like the figma model. The guy had used tailwind. That's when I realized that tailwind is great for rapid prototyping, but if you really want something precise, nothing beats raw css. Needless to say, the mission was hell.

Ideally design would be using a design system - you can alter all the spacing utilities in Tailwind to match the design spacing if they don't go by the multiples of 4 that Tailwind does.

If you're getting Figmas with inconsistent padding / margins everywhere, no CSS framework is going to save you.

Really great list, I didn't know about most of these. `line-clamp` is finicky though, and often doesn't work the way I'd expect.

I am a recent Tailwind convert. Still in the honeymoon phase, though. Stuff like this to learn more is really great, thanks!

css can do all of that natively

Yep but Tailwind is not about replacing native CSS.

Yeah, tailwind supports /80 for opacity or you can write opacity:.80

which is clearer?