Everyone hates Tailwind, until they don’t
“I hate Tailwind, it’s so ugly”
I’ve heard this a lot. And I get it. I really do. When I first saw Tailwind, I thought it was the ugliest thing I’d ever seen. But then I started using it, and I realized how powerful it is.
To make it less ugly, you can use two simple tricks:
- Prettier plugin to enforce consistent class ordering
- Tailwind Plugins
Also, it is not so bad if you are using front-end frameworks like React, Vue, or Angular. Components are a great way to abstract away the ugly classes.
“But I can’t remember all the utility classes”
- Use a cheat sheet.
- Use IntelliSense in your editor.
- Use inspector tools to see design system CSS variables in :root. Tailwind 4 is based on CSS variables, so you can see all the classes in the inspector. Plus, you can change them on the fly to see how it affects your design or add custom ones to your Tailwind theme.
“Why not just use Bootstrap?”
- Tailwind is more flexible. You can create your own design system with it.
- Tailwind is more performant. You only use the classes you need.
- Tailwind is more maintainable. You can easily change your design system by changing one file.
- Tailwind is more accessible. You can use it with any front-end framework or even vanilla HTML.
- Each CSS framework that provides you with higher-level components like buttons, cards, etc. eventually makes it harder to maintain and customize. You want style basics, not pre-built components. Tailwind is the best way to do that, because it’s utility-first.
“Why not just use inline styles?”
This question is so frequent that official Tailwind documentation has a whole section dedicated to it.
“It makes HTML size bigger”
The moment your HTML size becomes a bottleneck, you have bigger problems. Tailwind is not the issue here.
Furthermore, this might be a hint that you need to extract some of the classes into components. This is what’s JS frameworks are for.
Also, the difference of CSS and Tailwind in this aspect is that with Tailwind you create less duplicated code in your bundle even if it’s in your HTML. And when using CSS, you have to create a new CSS file for every new component and new custom CSS classnames for each element. I will repeat this again and again: TW scales better.
Why I love Tailwind
1. Speed
Tailwind is by far the fastest way to build a website. You don’t have to write any CSS. You just add classes to your HTML, and you’re done. Also, you don’t have to worry about naming things nor about creating new CSS files for every new component, which can be a huge time saver.
2. Flexibility
Tailwind is incredibly flexible. You can create your own design system with it. You can easily change your design system by changing one file. With Tailwind 4 this is even easier because it is based on CSS variables.
3. Performance
Tailwind is very performant. You only use the classes you need. This means your CSS is smaller, and your website loads faster.
4. Scalability
Tailwind is very scalable. You can use it on small projects or large projects. You can easily scale your design system with Tailwind. Utility-first CSS scales better than traditional CSS because you don’t have to worry about specificity issues. Also your bundle size is smaller because you only use the classes you need.
5. Browser support
Tailwind has great browser support. It works in all modern browsers. You don’t have to worry about compatibility issues with Tailwind.
Comparison with scss modules approach
| Why it matters | Tailwind v4 (utility‑first, CSS‑first config) | SCSS modules |
|---|---|---|
| Spin‑up & iteration speed | One CSS file, one CLI command: @import "tailwindcss"; and start writing markup. No separate config or build‑tool tweaks required. | Must wire Sass into your toolchain and jump between .scss and markup files for every tweak. |
| Design‑system tokens | Tokens live right inside your stylesheet via new @theme and @layer theme blocks, so palette/spacing changes happen where you write CSS — no JS config necessary. (You can still opt‑in to a tailwind.config.js/@config if you prefer.) | You roll your own $variables, maps, or mixins and make sure every module imports them consistently. |
| Responsive & state variants | Same terse syntax: sm:bg-primary dark:hover:bg-primary/80. v4’s Lightning CSS engine makes these compile even faster. | Hand‑written media queries and selector gymnastics in every file; mixins help but add boilerplate. |
| Bundle size | JIT still purges unused utilities; production CSS often less than 10 KB gzipped. No separate config means one less file that can accidentally enable extra plugins. | Tree‑shaking plain CSS is difficult; bundles grow linearly with components. |
| Naming & cognitive load | No bikeshedding over class names. Utilities (flex gap‑4) describe the outcome directly. | You invent names (.Card__title--small) and keep a mental map of them. |
| Tooling & ecosystem | VS Code IntelliSense, Prettier, ESLint plugins, and ecosystem libraries (daisyUI, shadcn/ui) all updated for v4’s config‑in‑CSS approach. | Mature Sass tooling exists, but fewer prefab component kits and plugins are copy‑paste ready. |
| Design‑to‑code hand‑off | Figma → CSS variables now match 1‑to‑1; designers don’t need to know about a hidden JS config file. | Token drift inevitable unless someone audits Sass variables regularly. |
| Learning curve for new devs | One mental model: compose small classes. On‑boarding quicker because there’s no extra JS config file to explain. | Must learn project‑specific Sass architecture, naming conventions, and where styles live. |
Where SCSS modules can still win
| Use‑case | Why SCSS Modules might beat Tailwind |
|---|---|
| Highly bespoke visuals | If a component needs dozens of micro‑adjustments, a dedicated Sass file may stay more readable than a utility soup. |
| Algorithmic styles | Complicated keyframes, calc(), or @supports fallbacks are often easier to author in Sass mixins. |
| Non‑HTML targets or strict legacy stack | Styling emails, SVG sprites, or large legacy products might justify staying with Sass to avoid a full migration. |
Common 2025 workflow
Most teams blend the two:
- Tailwind v4 for 80‑90 % of everyday layout, spacing, color, and responsive work.
- Tiny Sass layer for edge‑cases: elaborate keyframes, third‑party overrides, or super‑custom components.
- Optional JS config when you really need things like
pluginsor elaborate theme extensions — now added with@config "./tailwind.config.js";in your CSS.
Conclusion
Don’t knock it till you try it. Tailwind is a powerful tool that can help you build websites faster, more flexibly, and more accessibly. Give it a shot, and you might just fall in love with it like I did.
