Am I Misunderstanding TailwindCSS?

Adam Wathan, one of the creators of Tailwind, wrote about his transition away from writing "conventional" CSS when he started the project: https://adamwathan.me/css-utility-classes-and-separation-of-...

The Tailwind docs also cover a lot of your questions: https://tailwindcss.com/docs/utility-first

From my point of view, I made the same realisation as Adam and found Tailwind suits my needs very well. Learning and using only the classes provided by Tailwind is actually very freeing and helps me rapidly build out a design. I've also found projects built with Tailwind to be very maintainable.

However, if you don't feel like Tailwind is right for you then don't feel any pressure to use it, regardless of how many people sing its praises.

I think that the issue at play here is basically the same than the debate about FP vs OOP for systems architecture. One tries to encapsulate information, by distributing it, while the other tries to completely separate both.

These are differennt strategies leading to different paradigms. Looking at one from the point of view of the other will make you think they are using obvious anti-patterns and just getting it comoletely wrong. But this is somewhat an illusion, because they are in fact trying to achieve different things (or the same things with different strategies).

Classical CSS is like FP. It insists in completely separating information (HTML) and operations (CSS). This works well when you have a priory knowledge about the totality of your HTML and its internal structure. Therefore, it works well in small/simple systems or systems with a simple structure (blogs, ...). This model is favoured by designers and developers of "simple" systems (the ones with an a priori known structure).

Tailwind and similar frameworks focus in encapsulation and composability. As OOP, they make it easier to compose modules developed by different teams with little coordination between them without risking too many conflicts. They are designed for modularity and scalability. Therefore, this model is favoured by developers using component based JS frameworks like React and targetting very big systems (like FB, Amazon or any similar complex systems).

I think that, depending on the context, one paradigm can be more appropriate than the other, but it makes little sense to say that one is right and the other one is wrong as a general statement.

No, you’re not missing anything. Tailwind is a disastrous anti-pattern that the whole web dev community should be fighting against. (Web dev here since ‘96.)

I don’t know CSS. I agree even I don’t understand TailwindCSS advantage. It’s like writing inline styles which we are told is a bad practice. Plus to get create a button rounded I end up adding so many classes in my html. My html is now is hard to read. Again I have to know all possible combinations to style something in my html. Now tailwind css guys come up with ui components and we might need to pay for it. I’m definitely missing something here or some ignorance

>I understand CSS, what the properties do, individually. But I lack the creativity and design skills required to come up with half of what is provided by those frameworks. I could do it if I had infinite time and patience, but I don't.

You know the syntax but you don't know how to think in CSS. Learn how to create layouts. Learn flexbox and grid. Watch a few YT videos to and try to design something yourself.

For example take a website like Facebook and try to design the log-in form like that. That's how you learn. No one is born with perfect design skills and it doesn't take a lot of time to learn how to make designs so awesome you won't believe you did them yourself in pure CSS.

You are missing something: React. Tailwind is designed around the React methodology. If everything in your website is component (yeah, including buttons, links, headers, etc...) then Tailwind suddenly makes lots of sense.

I have also been very confused about the popularity of TailwindCSS and similar CSS frameworks such as WindiCSS or UnoCSS.

I remember learning that HTML must not be about presentation. The CSS Zen Garden was the state of the art for web development. But as I read, this ship has sailed. The reality is that these frameworks are actually convenient to use and very appreciated by the large majority of web developers. Especially the younger ones. It's not much more than a syntax with some sugar compared to the HTML style attribute, but if it makes web developers happier I'm using it.

Using pure tailwinds involves a lot of boilerplate. Using daisyui (a pligin) you can use bootstrap sytax for default components and/or include more tailwind selectors. The best of both world

https://daisyui.com/

Some features Tailwind provides:

• Consistent language for applying colors, and utilities for modifying colors and opacity.

• Consistent widths, sizes, and breakpoints for text, borders, containers, etc.

• Consistent and concise language for media queries (breakpoints, dark mode, etc.).

• Enables inline specification of hover state, group state, etc.

• Less verbose than using actual inline styles.

The other comments missed that the classes enable you to make the html responsive very easily. They allow you to compose at a good level instead of guessing if you have a css class defined already that kind of does what you need. It standardizes and scales well. What I mean by that is, if you have a large team there’s no guessing what other people have defined already. They all can refer to the docs and move quickly. Anything that’s unused can get purged pretty seamlessly.

Another big plus is the ability to use things like TailwindUI which has saved me countless time and sites like TailwindComponents.

> Instead of writing CSS, I add classes to my HTML. Ok, but I don't want to rewrite everything all the time, it would be like using the inline style attribute.

> Ok, then I install PostCSS, and start writing classes with @apply. Wait, hang on, isn't that just writing plain old CSS with a new syntax and new names to learn?

These questions are covered in the basic docs:

https://tailwindcss.com/docs/reusing-styles

https://tailwindcss.com/docs/utility-first

- Reuse styles using components, not classes.

- Inline styles don't allow responsive behaviour, utility classes do.

The above also comes with accepting that the plain old CSS approach doesn't scale and makes you do stuff ("best practices") for no real benefit; it pushes you to make premature abstractions, name things that don't need to be named, and split things up between files that don't need to be split up.

If you don't agree with this though (more likely if you don't work on complex designs), you'll be fighting against Tailwind. Saying that, I think a lot of people comment without having read the basic docs and are having knee jerk reactions to what they see as going against best practices without really trying to understand it or weigh up the pros and cons.

TailwindCSS is really good for HTML template engines.

The idea is that you can’t separate style from HTML anyways, e.g. certain layouts and widgets require you to use multiple HTML components instead of just styling a base component. Or even if they don’t require, it’s a lot more straightforward than using some obscure CSS hack or possibly unsupported new feature (centering one element in another comes to mind).

So instead of writing HTML directly and then styling it with CSS, you write HTML components and then reuse those components. Each component basically has its own style, and it’s a lot easier to just define it inline using TailwindCSS.

Another benefit of TailwindCSS is that it’s really concise and has automatic support for custom color palettes and size units. In React and Vue there are many ways to define inline styles, some with typing guarantees, but still Tailwind tends to be easier.

I think the primary advantage of tailwind comes when you use it with JS components e.g. React, Vue, etc.

Instead of writing ".widget a" which will leak into its child components' anchor tags, you just directly style the anchor tags of the parent widget

This keeps css simple and isolated so you don't need to waste time trying to figure out the specificity to override some style