What’s Good About Tailwind CSS

1. The Pain of Naming

The first advantage that comes to mind is not having to name things.

There’s a saying: the two hardest problems in software development are caching and naming.

Especially naming CSS classes – oh, it’s really tough. Most of the time, we name a class based on its container: if it’s a wrapper, we call it xx-wrapper; inside the wrapper, we call it item; more specifically item-title/item-button.

But sometimes the layout changes and you need an extra div wrapper. Then the trouble starts. By convention, you’d call it xx-wrapper, right? But that name is already taken, so what do you do? That’s when you realize naming becomes tricky, doesn’t it?

You might think of a new word, like xx-container. Seems to solve the problem, but actually it makes the existing CSS class naming rules even messier, because now you don’t know when to use container and when to use wrapper. What’s the difference?

And what if you need to add yet another layer of div later? What then?

Later on, to solve this naming problem, we got the BEM methodology or some of its variants.

Simply put, you name classes by directly connecting the DOM structure with dashes – you don’t have to worry about running out of words when nesting gets deep; you just keep adding dashes.

For example: the list inside an upload component is called upload-list, each item inside is upload-list-item, and inside that, the name is upload-list-item-name, and so on, just keep stacking dashes.

This naming convention is pretty good – it finds a balance between our limited vocabulary and deeply nested DOM structures.

So when Tailwind came along, it felt like it was saying, “Buddy, stop wasting your effort. What’s the point of typing all those dashes? Instead of that, do something useful – just write the width, height, and other properties directly here, so at least you can see what it does at a glance.”

2. Automatically Cleaning Up the Mess

No matter if you’re at a big company or a small one, whether your team does Code Review regularly, how strict your coding standards are, or how high your test coverage is, you have to admit that CSS is the weakest link in code quality. Most people don’t care about CSS code as long as the component looks fine. Why doesn’t anyone care? It’s not that front-end developers don’t care about KPIs – it’s that CSS is hard to test and hard to evaluate in terms of code quality.

CSS stands for Cascading Style Sheets. Once you understand the meaning of “cascading”, you know why it’s hard to test and maintain. Cascading means you can’t judge a style class solely by looking at its definition or syntax – it’s affected by its parents, children, and many other factors. When multiple classes pile up, complexity skyrockets, and you can’t know what it will actually look like until you open it in a browser.

So even if you’re an experienced front-end developer, you hesitate to touch CSS files left by others. Want to modify someone else’s code? Forget it – just override it. It’s not your fault; it’s called cascading! That’s the nature of this language. As a result, CSS files become a pile of garbage and duplicated code, practically unreadable. No one looks at them until something breaks, and even then, they hold their noses, check what’s wrong, but instead of fixing it, they just add another layer of garbage.

Besides, I’ve lost count of how many times I’ve written display: flex inside xx-wrapper.

Fortunately, when writing Tailwind, this guilt of dumping garbage is greatly reduced.

On one hand, CSS files are almost eliminated.
On the other hand, during build time, Tailwind automatically merges duplicate styles. Even if you write display: flex ten thousand times, after the build it becomes just one line: .flex { display: flex }. This is very useful in large projects and effectively reduces CSS file size.

3. Other Advantages

• Great for Backend Devs Learning CSS: No need to dive into advanced CSS topics like various selectors (+, *, ~, ,, space, >, pseudo-classes, pseudo-elements) – just use presets, and presets won’t look too ugly. You don’t even have to learn different units to make layouts responsive across screen sizes. Use lg for large, sm for small, xl for extra large – if you’ve bought clothes, you get it.

• Easy Dark Mode: Without Tailwind CSS, implementing a dark mode for a page can be tricky – you might need to define a bunch of color variables and combine them with media queries. The complicated part is that you have to set a variable for every color you use, because in dark mode they could be completely different values. But with Tailwind CSS, you just add a dark: prefix.

• Colocation: No need to create a separate CSS file and jump back and forth to check the details. Sometimes I just need a div to center its content – Tailwind makes it easy, but with traditional CSS I’d have to think of a name, switch to the CSS file, and write a bunch of repetitive code. In short, Tailwind CSS saves a lot of trouble.

• AI-Friendly: Possibly also thanks to colocation – no need to cross multiple files, making it easy for AI to read and write. Also, Tailwind’s atomic CSS classes avoid selectors, style inheritance, and style overrides, which reduces the complexity for AI to understand.

• Copy-Paste from Other Tailwind Websites: For instance, there’s this site https://io.google/2025/. If I like some design element, I can just copy and paste it into my own project. Open-source sharing has never been easier.

• Easier Team Collaboration: Or rather, you don’t have to spend time understanding other people’s class naming and CSS structure. Maybe you’ve experienced working with a colleague who is very meticulous about CSS – they have a full reset, load several CSS files that layer on top of each other, causing confusing style specificity, and your styles often don’t work. You can’t say anything because your teammate thinks their approach is particularly sophisticated and is best practice. But with Tailwind CSS, there’s none of that drama – just keep piling on styles.

• UI Components: Some awesome component libraries are built on Tailwind, like shadcn/ui and magicui. If you don’t embrace Tailwind, you might miss out on them. Especially shadcn-ui, which is completely different from libraries like Element UI or Ant Design. If you’re building admin dashboards that don’t require much front-end sophistication, you can quickly finish by stacking Element or Ant Design components. But for customer-facing projects or those with high front-end requirements, you often need to extensively customize components. Element UI is hard to customize – you’re limited to a few props or style overrides. But shadcn-ui generates the component source code directly into your project, which is perfect for customization. I’ll go into detail in another video. Click subscribe.

• Lastly, a crucial point: It can help you constrain UI designers. Especially if your company has many customer-facing projects and your UI designers are creative, building a component library for the front-end is nearly impossible – designers can come up with dozens of variations for a single button. How do you encapsulate that? But if you choose Tailwind CSS, you can ask the designer to agree on the main color palette, the key layout widths, heights, and spacing in advance. This forces the UI designer to be more restrained in their designs, making components reusable.