Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"At some point, hundreds of utilities later, the code you've written doesn't look pretty."

Personally I find diving through a bloat of identifiable tailwind classes allows me to review/change/adapt/create UI code MUCH QUICKER than having to re-learn some other abstraction or naming convention that some other developer came up with.

Complaining that lots of Tailwind classes "don't look pretty" makes me think the author has never worked on large projects/refactors using it.

To me Tailwind hits the perfect level of abstraction:

- not too low-level; allowing us to easily review/identify patterns in the code (p-0, leading-3, etc..)

- not too high-level; allowing us to not have to relearn a visual/naming pattern for every new project (.card, .button, etc..)

It boils down to being a search problem: how much of a language/DSL feature can I fit in my head? Reviewing a wall of CSS is harder for me to "search through". On the other hand a wall of Tailwind hits the right spot.



I’ve worked on some large projects including refactors with Tailwind and my view is opposite. I can see how Tailwind would work on small projects, or ones where the designer never touches the styling inside the code. But on the other hand, avoiding naming because it’s hard isn’t how I approach organising design, and it doesn’t sound like a good approach to coding either. But I can see how there may be a need to bypass it in projects where there is no designer, or a design system.


You don't avoid naming - you name the components and the styles live in the components. The key is to avoid the false separation of concerns of style and structure.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: