Comment by jasim | Hacker News Reader

Comment by jasim | Hacker News Reader

Parent Full thread

Tailwind makes it very easy to change theme by changing just a single configuration file: https://tailwindcss.com/#designed-to-be-customized

It is very liberating to use Tailwind instead of creating unique CSS classes for every div in a page. The code is much more maintainable - in a single stroke Tailwind gets rid of selector specificity issues, design inconsistency, and naming woes.

From a programming perspective, the conventional style of "semantic" CSS classes creates deep and fragile coupling between markup and CSS. It goes against everything good code is supposed to be - when you change the structure of the HTML you're forced to change the CSS, and if you truly use the power of CSS selectors, then modifying CSS becomes a difficult enterprise: one change can create multiple unrelated changes at a distance.

Tailwind solves all this, with just two downsides: until you spend a few hours mucking with it, the markup look will look unwieldy, and you have to be ready to really think about semantic CSS and "separation of concerns" dogma we've taken for granted for so long.

Bit of a tangent, but perhaps the issue with separation of concerns isn't so much that it's a bad idea, it's that it's not always a good idea; and secondly that css doesn't really enable separation of concerns like that. It's a fine idea to be able to give (essentially) a style a meaningful name, but only if you know what the meaning is and probably only if you intend to use it several times. Since CSS cannot really create complex styles from scratch meaning that you need wrappers and separators and whatnot as purely style elements, true encapsulation that's easy to use without knowing the implementation isn't really feasible.

Hence "separation of concerns" - to the extent that it's a good idea in the first place - doesn't work for html+css, and similar concerns mean it doesn't work very well for html+scripts.

Put another way, leaky abstractions are worse than no abstractions. Better to keep things transparent and merely expose helpers, instead of pretending you can hide complexity when you cannot really hide it.

I'm looking at the example: https://tailwindcss.com/docs/utility-first

So, if I'm making a theme, and I want a different color for the text, I have to replace "text-gray-900" with my hex code for purple?

Also, what if my theme is about making the design more compact, or increasing density? How do I customize thousands of elements with different combinations of class="ml-6 pt-1"?

Oh, and don't get me started on "bg-white rounded-lg". God forbid your theme wants squared boxes on black background.

Don't use `text-gray` if you're building an app that needs to be themed like that. Instead use `text-secondary` or a similar name that you'd otherwise use in a themeable system. Tailwind lets you define _every_ single design token in the system and comes with zero opinions there.

If you want to change density of the design, you can change the spacings centrally in the configuration itself. But if you need a non-proportional change, then it isn't any different than BEM+SASS environment where you'd have to go into every CSS class and make the change. I think it is even better than BEM here because you only need to change classnames in HTML, which is co-located with the style, and it doesn't cause cascading changes due to specificity etc.

To me the opinions you hold seem to come from not having tried it in good faith, which was how I used to judge functional CSS as well. If the current CSS style you use serves you well, that's fine you don't have to explore. But if you've wondered whether there is something wrong with the way we do CSS today, then Tailwind could be an eye-opener.

Reply on news.ycombinator.com