I just started using Tailwind for a small project and love it! I thought I'd respond to the author's points:<p>> Tailwind Makes Your Code Difficult to Read<p>I think this is a preference, not a fact. I tend to write 2-dimensional CSS (I know the standard convention is 1D) so seeing a bunch of classes one after the other on the same line doesn't bother me.<p>Regarding the abbreviations being difficult to parse, I don't find it so. And, do you want short class definitions or do you want long and descriptive class names?<p>> Tailwind Is Vendor Lock-in<p>I'm not convinced. <i>Every</i> framework is lock-in. Otherwise there'd be no point.<p>> Tailwind Is Bloated<p>Possibly, but it seems to trim itself down when compiled to production quite nicely. Paired with minification/gzip, doesn't seem like such a big deal.<p>> Tailwind Is an Unnecessary Abstraction<p>I like the promises it gives. "Here are some predetermined boxes your design can fit into, if you need to change them, do it via the config." In other words, you're constraining yourself. I think this is important. Even on teams with designers, the design can evolve over time and you'll have one section of an app looking different from another. Tailwind enforces a set of good practices. Maybe I like this because I'm not a great designer at all, but it seems to me this kind of constraint could have helped many projects I've worked on in the past (ones that <i>had professional designers</i>).<p>Secondly, regarding "What exactly is the difference between using @apply and just using the CSS rules that correspond to your utility classes?" Well, because your utility classes are still subject to the constrains I mention above. The documentation specifically only recommends doing this for places where something is too small to be its own component, but too common to repeat the same class names over and over. Sure, you can misuse it, but I found the documentation obvious how the best practices here.<p>"Because instead of repeating styles in your CSS, you’re now repeating them in your HTML, through class names." I think Tailwind specifically makes sense in the context of components. If you're repeating the same classes over and over again, you're doing something wrong.<p>> Semantics Is Important. Tailwind Forgoes It.<p>I can see both sides to this. The one comment I'll make is that in the cases where I've vehemently stuck to semantics, it has been wonderful to <i>build</i> but horrible to <i>change</i>. Semantics makes a tone of sense, until things start shifting around, and then you've got half of your classes referencing some object that's no longer there, or a thing that used to live here, but now lives there, and only some of the styles moved and some were copied etc etc.<p>When I first saw Tailwind, I thought "wow, this is just inline styles++, how stupid." Now I kind of see the magic behind it.<p>> Tailwind and Dev Tools Don’t Play Nicely<p>This might be true, I haven't really done much devtools CSS debugging with TW yet.<p>> Tailwind Is Still Missing Some Key Features<p>It also defines "dark" but I haven't seen anything about custom themes in general. What if I have more than just a normal mode and dark mode? I'm curious how one would build themes on top of TW.<p>> With frameworks like React and, more recently, Svelte, it’s never been easier to write CSS without leaving your markup, and without resorting to inline styles. You don’t really need BEM, either.<p>This is true, and I'm excited to try and build something more complex in Svelte and see how it goes.