Tailwind won. The data proves it. The adoption proves it. If you're arguing against Tailwind in 2025, you've already lost.
Such loud words for a simple tool, not even a new paradigm =) I don’t like this kind of cultism. PHP is still being buried every year, React is decent, but Vue and Svelte have already replaced it in many projects - and tons of teams choose them, etc., etc. ...
Migrating away from Tailwind is like migrating away from jQuery was. Possible, but so painful that most people just don’t.
Yep. That’s why I honestly call it cancer. Once you use TW in a component library, you’ll have to drag it into the website that uses those components. And if it’s a legacy project - are you sure you won’t break anything with Tailwind’s built-in style reset and generic class names? I’ve personally seen cases where Tailwind broke existing logic because the site already had a global .hidden class doing visibility: hidden, and then Tailwind came in and wrecked the layout with display: none.
In short: it’s just a tool. And, as an engineer, you need to decide where it belongs and where it doesn’t. The key is not to fall into tool worship and not to force it where it causes more harm than good. Because then you end up with stuff like:
A bunch of regular CSS with BEM
Tailwind appears and some components or page sections are written in it
Hacks start: @apply overriding original CSS or even writing regular CSS classes stuffed with @apply and Tailwind classes inside lol.
Hacks with custom values if your designer has his own vision: w-[142px], etc.
I won’t even talk about how “readable” markup becomes with Tailwind. It’s just mush on the level of minified code. And since you can’t always see every scenario live - maybe there’s no such user or the feature is disabled right now - you’ll have to fix or add something based purely on code. Now be honest: what’s more readable - an element with a couple of clear BEM classes or a component/page (especially 1k+ lines of markup) stuffed with div/a/img/p/ul/li, all seasoned with Tailwind classes? With 2 themes. Across multiple breakpoints - with all those sm/md/lg. Mmm ~
Plus, one more interesting and not very pleasant point: I know several people who dislike this technology but are afraid to speak about it publicly, because others might think they’re unprofessional or against progress lol. Not sure how widespread this is, but it’s clearly unhealthy. It can create a false impression that everyone uses Tailwind, everyone more or less likes it, it’s won all the awards, taken over all the projects, etc. When in reality, things are very different.
So personally, I consider Tailwind a decent technology for its niche: prototypes or quick features where - and this is key - you probably won’t come back to later. Because developers spend most of their time reading code, not writing it. And that instant “Haha, I’m doing flex align-center brrrr” savings can bite you hard later, when you have to untangle all this in 5-6 years.
Idk bro... as soon as you said "cultism" I was lost, I expected better communication from an engineer, but I guess they ain't building them like they used to.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Such loud words for a simple tool, not even a new paradigm =) I don’t like this kind of cultism. PHP is still being buried every year, React is decent, but Vue and Svelte have already replaced it in many projects - and tons of teams choose them, etc., etc. ...
Yep. That’s why I honestly call it cancer. Once you use TW in a component library, you’ll have to drag it into the website that uses those components. And if it’s a legacy project - are you sure you won’t break anything with Tailwind’s built-in style reset and generic class names? I’ve personally seen cases where Tailwind broke existing logic because the site already had a global
.hiddenclass doingvisibility: hidden, and then Tailwind came in and wrecked the layout withdisplay: none.In short: it’s just a tool. And, as an engineer, you need to decide where it belongs and where it doesn’t. The key is not to fall into tool worship and not to force it where it causes more harm than good. Because then you end up with stuff like:
@applyoverriding original CSS or even writing regular CSS classes stuffed with@applyand Tailwind classes inside lol.I won’t even talk about how “readable” markup becomes with Tailwind. It’s just mush on the level of minified code. And since you can’t always see every scenario live - maybe there’s no such user or the feature is disabled right now - you’ll have to fix or add something based purely on code. Now be honest: what’s more readable - an element with a couple of clear BEM classes or a component/page (especially 1k+ lines of markup) stuffed with
div/a/img/p/ul/li, all seasoned with Tailwind classes? With 2 themes. Across multiple breakpoints - with all thosesm/md/lg. Mmm ~Plus, one more interesting and not very pleasant point: I know several people who dislike this technology but are afraid to speak about it publicly, because others might think they’re unprofessional or against progress lol. Not sure how widespread this is, but it’s clearly unhealthy. It can create a false impression that everyone uses Tailwind, everyone more or less likes it, it’s won all the awards, taken over all the projects, etc. When in reality, things are very different.
So personally, I consider Tailwind a decent technology for its niche: prototypes or quick features where - and this is key - you probably won’t come back to later. Because developers spend most of their time reading code, not writing it. And that instant “Haha, I’m doing flex align-center brrrr” savings can bite you hard later, when you have to untangle all this in 5-6 years.
Idk bro... as soon as you said "cultism" I was lost, I expected better communication from an engineer, but I guess they ain't building them like they used to.