| For me Tailwind CSS solves a cognitive problem: I find that switching between CSS and HTML files reduces my development velocity substantially (maybe I'm getting old). I was always a bit wary of CSS frameworks, and I preferred writing "actual" CSS and used mostly CSS/SCSS before I discovered Tailwind CSS. Interestingly, even before I discovered Tailwind CSS, I was already getting into the habit of using utility classes like "flex", "flex-wrap", because it made a lot more sense *to me* to see those in the HTML. I personally find the examples given in the blog post contrived. Take the "hard to read part", for example, this is how I normally format my HTML using Tailwind CSS: <div class="
w-16 h-16
md:w-32 md:h-32
lg:w-48 lg:h-48
"></div>
Even if you are using styled-jsx or any framework that gives you the ability to write "regular" CSS, it still wouldn't beat the example above in terms of readability. As such, the following paragraph just doesn't make sense:> I’m comfortable reading other people’s code, and making sense of their logic and relating their markup to their CSS. Assuming that we are not talking about component-scoped styling here (otherwise the point made would be moot), with Tailwind CSS you can instantly relate CSS to markup without switching between files and hunting down all relevant class names in the example given above; this is arguably also easier when you are not working with the source and just debugging on the front end. > But if I have to look at ~1000 LOC changes in a PR, and most of that is coming from long strings of class names, I’m not going to be happy. It’s also going to be more difficult for me to make suggestions that could eliminate redundant CSS or simplify your markup. I have never dealt with ~1000 line of changes in a single PR, but that sounds pretty broken and there is an abstraction problem that is much worse happening elsewhere and irrelevant to the argument. The last line also sounds like a throwaway without any solid example to prove it: even if switching between markup and CSS files is not taken into account, I can't imagine hunting down redundant CSS would take longer with Tailwind CSS. If the redundant classes are on the same element you can see it instantly; if they are on different elements, it would still take similar amount of work to debug and find them? Assuming that there are no redundant classes, then there isn't much to be simplified because the whole point of Tailwind is to have (managed) complexity in the markup instead of having it in the CSS. I personally would rather have it in the markup, but that's just me and I can't say if it's better or worse. > With Tailwind, you’re forced to interpret semantics on the fly. I find it easy to just ignore class names and focus on content when I need to with the way I structure my code. Maybe a lot of people don't realise that it's okay to, or feel comfortable with, splitting class names and attributes onto multiple lines. Just one more point on being bloated, note that on Tailwind CSS's website they say: > Tailwind automatically removes all unused CSS when building for production, which means your final CSS bundle is the smallest it could possibly be. In fact, most Tailwind projects ship less than 10KB of CSS to the client. For reference, the blog's CSS is 12.12 KB gzipped. Most of the rest of the post follows a similar pattern that's just out to trash Tailwind CSS. As others have already pointed out, this may end up being a 50/50 thread of personal opinions after all, but it seems that we keep getting more and more of these sensationalised hate posts that are just based on personal preferences... |