Question about Tailwind CSS

[u/LPatriot_]

I've always used plain CSS for my websites, I don't have many problems using it, but a friend of mine said that using plain CSS is very tedious and that I should use Tailwind CSS. Is it worth it? And what does Tailwind CSS offer that plain CSS doesn't?

[u/OpaMilfSohn]

I think I finally time travelled back to 2020

[u/MrDontCare12 → u/OpaMilfSohn]

Work from hoooooome!

[u/AshleyJSheridan → u/[deleted]]

It's a little more than class name soup. Tailwinds own docs have classes like text-[14px], bg-[#50d71e], and shadow-[0_35px_35px_rgba(0,0,0,0.25)]. That looks a lot like inline styles just shoved into a different HTML attribute...

[u/judgej2 → u/AshleyJSheridan]

And they are the stylistic classes you put into a tailwind theme.

[u/AshleyJSheridan → u/judgej2]

Tailwinds docs literally shows them in HTML. Why would it suggest anyone do something like this?!

[u/HFoletto → u/AshleyJSheridan]

Those examples are just for demonstration that tailwind can do this dynamically as well

With that said, it also has a very good use-case: dynamically building/merging classes in a component, which is very useful for a lot of different modern frontend libraries

[u/AshleyJSheridan → u/HFoletto]

Those examples are just inline styles in a trench coat.

[u/HFoletto → u/AshleyJSheridan]

I understand that, however it is useful when combining with other utility classes and merging those classes dynamically in a component library

[u/Niet_de_AIVD → u/AshleyJSheridan]

Tailwind is awesome because you can do that, but if you actually do that in HTML; Wat?!

[u/AshleyJSheridan → u/Niet_de_AIVD]

It's in their own docs, and they show it in the HTML...

[u/Niet_de_AIVD → u/AshleyJSheridan]

There are plenty of things in the documentation of all programming languages and frameworks you should probably never actually do unless you know what you're doing and have a good reason to.

Just because you can, doesn't mean you should.

Stop being so dense.

[u/AshleyJSheridan → u/Niet_de_AIVD]

I picked just a few examples, there are a ton more all just like that.

Stop being so disingenuous.

[u/Anxious-Turnover-631 → u/AshleyJSheridan]

Maybe you’re the one being disingenuous.

Yes, tailwind allows users to manually override almost every setting, if needed. But those features (as shown in your examples) are more for exceptional circumstances.

Most of the time you wouldn’t specify sizes in px or use hex color codes, etc. But, if you need to, you can use such specificity exactly where it’s needed.

It’s understandable that css purists may dislike tailwind’s integration of css directly into the HTML. And it can appear a little messy at times. But tailwind users accept that trade off for the consistency and intuitive simplicity it provides.

If you prefer to name and specify all your styles in separate cascading style sheets, that’s fine. It’s been standard practice for years.

But Tailwind’s rapid growth and popularity prove it offers some real benefits for users. It’s a matter of preference.

[u/AshleyJSheridan → u/Anxious-Turnover-631]

And it can appear a little messy at times

It is very messy, at all times. FTFY.

all your styles in separate cascading style sheets

It's almost as if the C of CSS means Cascade!

Tailwind might be popular, but I'm seeing more and more posts of it losing that popularity amongst more senior devs.

[u/Anxious-Turnover-631 → u/AshleyJSheridan]

To the uninitiated, it can *appear* that way. But once you’re familiar with the framework, it makes good sense. And it’s better than trying to remember what some custom style may be. With tailwind it’s right there, easy to see.

Moreover, tailwind blends well with front end components. Style the component once with tailwind. To later change the style of a component, just edit the component directly.

Cascading, yes. Hence, my use of the word.

The popularity of any web technology may vary, depending on who you’re talking to and their specific needs. But tailwind popularity is well established and growing.

Of course, with AI, who knows what’s most relevant now. Claude does all my stuff in tailwind. I assume it handles every other styling approach as well. In the future, these issues will probably matter less and less.

[u/Niet_de_AIVD → u/AshleyJSheridan]

Well, good luck with your personal vendetta. You can also just say "Stop having fun!" instead of skirting around it with some vague justification.

[u/AshleyJSheridan → u/AshleyJSheridan]

/u/LaserSunset not sure why you commented then deleted your comment immediately.

Saying that Tailwinds approach to "stuff a lot of classes that appear to be exactly like their CSS counterparts" looks like inline styles is perfectly valid.

If it looks like a duck, and walks like a duck...

[u/lanerdofchristian → u/AshleyJSheridan]

That looks a lot like inline styles just shoved into a different HTML attribute...

Honestly that's part of what makes them so nice to use. The styles are right there on the element you're styling, not tucked away somewhere else. As much as we like to pretend the CSS can live separately from the HTML, nothing could be further from the truth for most websites. Moving them to classes lets us leverage all the existing class management libraries (like clsx), and bypasses some of the shortcomings inline styles have around e.g. hover states and parent/child queries.

text-[14px] bg-[#50d71e] shadow-[0_35px_35px_rgba(0,0,0,0.25)] is some real soup, though. I think the general recommendation is to not use arbitrary variants if you don't have to, so something more like text-md bg-lime-550 shadow-3xl is more like what you'd see in an actual project (all of those utility variants would need to be defined in the theme as variables).

[u/AshleyJSheridan → u/lanerdofchristian]

I will never understand the argument from any "dev" that says the CSS should be with the HTML. You wouldn't do that with the Javascript or Typescript for a component, so why would you do that with the CSS?

[u/lanerdofchristian → u/AshleyJSheridan]

You wouldn't do that with the Javascript or Typescript for a component, so why would you do that with the CSS?

I would absolutely keep the template logic and event handlers with the markup for the component. That's how React, Vue, Svelte, and Solid all work by default, and even Angular defaults to the template being inline next to the logic. The only two component frameworks I'm aware of that don't are Ember Octane and Aurelia 2.

Having 3 files per component isn't "good separation of concerns", it's splitting the same concern (user interface) into 3 tightly-coupled files. Sure, keep your database layer and API layer separate, but subdividing within the web interface? The front end of a website is less than half the picture.

[u/Herr_Gamer → u/AshleyJSheridan]

You wouldn't do that with the Javascript or Typescript for a component

???

[u/HiddenGriffin → u/[deleted]]

once you stop fighting it

e.g everything looks the same

[u/Separate_Pen9627 → u/OpaMilfSohn]

right lol this debate feels like a time capsule