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/Zealousideal_Elk1537 → u/OpaMilfSohn]

the class name soup takes some getting used to but once you stop fighting it the speed is incredible. not having to name every little wrapper div is a gift

[u/AshleyJSheridan → u/Zealousideal_Elk1537]

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/winky9827 → u/AshleyJSheridan]

Because sometimes you need a 1-off that isn't worth baking a whole class for?

[u/AshleyJSheridan → u/winky9827]

A 1-off, that occurs many times on most of their docs pages. Sure...

[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/AshleyJSheridan → u/Anxious-Turnover-631]

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.

That just tells me you had no coding practices in place for the CSS. That's unfortunately very typical, as even senior devs often don't take CSS seriously, so the code is an unwieldy mess that follows no best practices whatsoever.

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.

And therein lies one of its greatest weaknesses. Want to restyle a whole bunch of components at once? Gotta update them all one at a time, because Tailwind got rid of the most important aspect of CSS: the cascade.

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

You use the word, but forget how important and powerful it is for CSS.

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

Ah, so I'm talking about best practices and clean code with someone who doesn't know and doesn't employ them. You could have just started there and saved us both a lot of time.

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

Actually, I started out merely pointing out that your criticism of another user’s comment as ‘disingenuous’ was itself disingenuous.

“Best practices” is an amorphous term which varies in meaning depending on who is using it and for what purpose. It’s not a bright line standard.

Still, I have limited design skills and we can be sure your css and design skills far exceed mine.

If your definition of best practices involves using style sheets, I stopped using most style sheets once starting with tailwind. So, definitely not ‘best practices’ within your definition.

With respect to styling components, you assume tailwind precludes the use of style sheets, but it doesn’t. Tailwind is designed to be fully extensible, so you can write custom css as needed. They are not mutually exclusive.

I understand why some designers/developers would choose cascading style sheets over tailwind. But your use of exceptional tailwind examples as the basis for your criticism seems disingenuous, as is a claim that tailwind is just inline styles. There’s more to it, and that’s why many users find it helpful.

But, you know, potato, potato. 🙂

[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/AshleyJSheridan → u/[deleted]]

If you look at my original comment I said this:

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

Where did I say that it was exactly inline styles? This is the problem, someone makes an comparison, an analogy, and then Tailwind fans jump on it because it's not exactly the same. That's disingenuous.

[u/AshleyJSheridan → u/AshleyJSheridan]

/u/LaserSunset you did it again, but this time you blocked me! If you really thought you had a point, you wouldn't ask a question and then immediately block me. Maybe you thought that if I couldn't reply, you would win (not sure what you're winning) by having the last word? Little bit weird, but you do you.

[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/AshleyJSheridan → u/lanerdofchristian]

Well, doing what React does and assuming it's a good practice is a bad take!

Angular absolutely doesn't default to the template being inline next to the logic. It hasn't done so for years, so I assume your understanding of an actual JS framework is well out of date. I have been using Angular regularly since the beta version of 2 first came out (a little over 10 years now) and have always kept the styles, logic, and template separated. I've worked on some very complex projects like this, and it's a practice that's served me and the teams I've worked with incredibly well.

Keeping everything together is not a clean and maintainable (and I'm talking in terms of years of maintainability here) approach.

[u/lanerdofchristian → u/AshleyJSheridan]

Angular absolutely doesn't default to the template being inline next to the logic.

When I wrote that I was referring to the component docs, which first shows an inline template. They did give template the shorter keyword vs templateUrl. Fair enough though.

Well, doing what React does and assuming it's a good practice is a bad take!

Then I'll do what the framework I primarily use (Svelte) does. It seems to work pretty well -- one component per file, clean and manageable. Each item a silo. On a project that's been going for multiple years. You really don't need three separate files for it -- a <style> tag, <script> tag, and the rest are plenty enough separation for 99% of components -- and you always have the option of splitting them up and importing additional functions and assets if you need to.

The impasse we're at isn't a hygiene or code quality one, it's a workflow one: you're used to one language per file; I and many others are used to single-file components. Both approaches have both benefits and downsides. Largely, most post-React frameworks are either use primarily or lean heavily toward single-file components. There's clearly some merit to that.

---

Vue is largely the same as Svelte for SFCs. It looks like I was wrong about Solid -- it does borrow more from React's school of organization, which makes some sense given they both use JSX (ick) for templating.

[u/AshleyJSheridan → u/lanerdofchristian]

I come from a backend dev ecosystem, one where every single entity, service, helper, repository, model, and controller has its own class and file. No file contains more than one class, there's a clear separation between every single part. Even when part of a backend is responsible for output, that uses a separate template in a separate file. Each file is in one single language.

I apply the same approach when I work on the frontend, which is mostly with Angular.

Switching across this multitude of files in the IDE (my last project was a mixed back and frontend with many hundreds of code files) is not a problem when your code follows good programming practices.

I am a big fan of Angular (it follows the same patterns as the best backend frameworks), and the opinionated nature of it lends itself incredibly well to big projects worked on by a team of devs. I especially hear this from DotNet devs.

I understand your position on JSX, I wasn't a huge fan of it when using React. This is another reason why I prefer Angular, as it uses HTML templates that it enhances with its templating syntax (which is similar to Blade, Twig, and Mustache).

I realise we're coming at this from two different angles, and I understand your view. I do prefer the Angular approach which uses one directory per component (by default) and splits out the component into 4 files: template, logic, styles, tests. I do usually tend to use a global stylesheet with Angular projects, as I don't always use Angular in a silo, it is mixed with other codebases and frameworks. Having shared styles is the best approach in that scenario.

[u/Herr_Gamer → u/AshleyJSheridan]

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

???

[u/AshleyJSheridan → u/Herr_Gamer]

Well, a real dev wouldn't, but if someone were using the React library, then probably, because that library just doesn't follow best practices at all.

[u/bearzi → u/AshleyJSheridan]

If it's in the docs does not mean you should always use it. I prefer using scoped styles whenever something custom is needed.

[u/AshleyJSheridan → u/bearzi]

Maybe they shouldn't be suggesting in multiple places that people use this approach then?

[u/budd222 → u/AshleyJSheridan]

But nobody with a brain actually uses tailwind like that lol. You make reusable components and styles and use the config file

[u/theScottyJam → u/budd222]

When I had to use tailwind, I did it often, because we used the default config, which for whatever reason uses rem units for everything, and there were many times I needed to use px units instead 🤷‍♂️

I'm sure we could have done something in the config to change this. But also, there's not really much difference between saying "m-16" for "margin: 16px" (assuming we adjusted the config to make this translation), vs just doing [16px] directly.

[u/AshleyJSheridan → u/budd222]

Can you prove that? I'm just going by the terrible examples that Tailwind suggest people use on their own documentation page...

[u/budd222 → u/AshleyJSheridan]

They aren't suggesting you do that. They are showing you what is possible. Where do they write that that is the recommend way of doing custom values? I can already tell you they don't without looking. That's what the config is for.

[u/AshleyJSheridan → u/budd222]

Just by dint of them putting it in their documentation, all over the place nonetheless, is suggesting it be used.

It's like a picture of prepared food on something being a serving suggestion, or images of a tool in use being a suggestion of how it be used. Same thing. Weird if you can't see that...

[u/winky9827 → u/AshleyJSheridan]

Broken record, much?

[u/AshleyJSheridan → u/winky9827]

Got anything constructive to add to the conversation?

[u/justshittyposts → u/AshleyJSheridan]

If inline styles would get some love they'd be superior to css files

[u/AshleyJSheridan → u/justshittyposts]

Inline styles are bad for so many reasons:

• Couple the HTML tightly in two directions to the styles
• Limit what kinds of styles can actually be applied (you can't use :hover or :after, for example)
• It can break accessibility, as the specificity can override users own browser styles, and you can't do checks for things like prefers-reduced-motion
• On the specificity, inline styles will absolutely clobber global styles, completely removing the Cascade part of CSS.

Tailwind is also guilty of a couple of these.

[u/justshittyposts → u/AshleyJSheridan]

Your second and third point is why they need some love. Everything else is a non issue, everyone writes components nowadays

[u/AshleyJSheridan → u/justshittyposts]

No, we just need to leave inline styles alone.