Thanks for confirming my suspicions regarding Tailwind. Their marketing loves talking about how small the CSS file size is vs semantic, but that code still has to go somewhere - and it's a bait and switch of "smaller css" with the cost of an inflated html file * The irony being in this article is that the CSS file is also larger
tbf the examples brought up in the blog post omitted semantic attributes such as lang and the whole dom structure (all the divs!) and the other data- attributes just to make it look even worse. OP is severely opinionated.
Tailwind vs. Semantic CSS
21–30 of 211 posts
Re: Tailwind vs. Semantic CSS
#22I don't agree with this post at all. It seems like it's been written by someone who never actually used Tailwind CSS: I had the same doubts before using it.
Re: Tailwind vs. Semantic CSS
#23.button-primary { @apply rounded-full focus:ring focus:ring-orange-500 ring-offset-4 outline-none px-6 py-3 etc...
and it gives you the best of both worlds. You refactor common css code into components and still have the amazing flexibility of utility classes.
Re: Tailwind vs. Semantic CSS
#24But you can have the best of both worlds with apply:
.card {
@apply p-2 rounded shadow text-gray-700;
}Re: Tailwind vs. Semantic CSS
#25Re: Tailwind vs. Semantic CSS
#26Re: Tailwind vs. Semantic CSS
#27I agree with the conclusion but that first example is so grotesque that it made me discard the whole article
One other advantage of tailwind is that it makes it easier to work collaboratively with people of different css level and it requires less review, less possible side effect. But it's clear to me that clean semantic well developed css is way better than tailwind.
Re: Tailwind vs. Semantic CSS
#28Author here. I implemented the commercial Tailwind "Spotlight" template with Semantic CSS and compared the differences in weight, amount of HTML and CSS, rendering speed, and best practices. I was surprised to find _that_ much overhead in Tailwind. Curious to hear your thoughts.
- Did you compare both versions of the page for feature parity across multiple browsers, devices, and breakpoints?
- what exactly accounted for so much bloat with the tailwind version of the site? Was it the CSS itself, or the classes that accounted for most of the difference? If it was the CSS, did you optimize it as per Tailwind's docs[1] so that unused styles weren't included in the final page styles?
- How much longer (if at all) did you take to design your selectors for the semantic version in order to reduce repetition, than you might have taken for creating the template with tailwind?
- How did the final sizes compare after brotli compression?
Re: Tailwind vs. Semantic CSS
#29I just moved our website from semantic to tailwind after I didn’t understand the semantic bits anymore. Main problem was: the semantic css was elegant, but understanding it again after half a year of not editing the page took super long. Tailwind is clear. The code looks uglier but I instantly know what’s going on. No hidden things. And no fear in editing a piece of html that it will break sth else. Huge upside.
Utility based css selectors that do one and single thing are clear and explicit, removing most (but not all) that hassle.
Re: Tailwind vs. Semantic CSS
#30In my experience, it isn't black or white. I've used tailwind along with components, e.g. .button-primary { @apply rounded-full focus:ring focus:ring-orange-500 ring-offset-4 outline-none px-6 py-3 etc... and it gives you the best of both worlds. You refactor common css code into components and still have the amazing flexibility of utility classes.