re: What are your thoughts on Tailwind CSS? VIEW POST

re: But you're putting the responsibility of appearance on the HTML, which it shouldn't care about. I realise it makes things easier for a backend dev ...

If you Google other people opinions on Tailwind you'll find numerous claims that it is actually more scalable, more maintainable.

To believe all those people you'd need to try it yourself.

Let's close this thread until you compare the traditional semantic CSS with Tailwind yourself on a real project.

Cheers! 😀

I found this just now. A poll on twitter. 😀

Hi @ashley , I like that you are fond of separating the concerns but when it comes to HTML and CSS whether you put them in a different file or not when you make changes you'd have to touch both of them as the HTML fully relies on the specifics of its design from CSS.

Tell that to the people who produce the wonderful designs at CSS Zen Garden. The HTML absolutely does not need to change with the CSS whenever there are changes.

It certainly does not!

But the reality is that 80% of the time HTML and CSS have to be changed simultaneously.

That's usually down to developers not separating concerns correctly. If it's adding/removing content, sure, that makes sense, but if it's just because you need to change the appearance of something, then it's a sure sign that something wasn't done in the cleanest way.

I think this can stem from two scenarios: devs who are up against the wall with a tight deadline (this is probably the number one reason for unclean code), or devs who aren't as experienced with frontend and don't know the best approach to a particular task. These scenarios happen, and they will always happen. What we should constantly try and do though is always learn and strive to do things the best way possible. Tailwind voids separation of concerns, and contributes (in a bad way) to the overall file size of the page. That's absolutely not the best thing to do for the web.

Tailwind improves separation of concerns IMO.

Maaate, your are so very wrong by saying that Tailwind increases page size. Actually, it's quite the opposite. Full gzipped CSS is 10-20kb for large websites. And 5kb for my entire medium website (~20 pages).

Again, you have no ideas what you are taking about until your try it.

I can't explain what is a red colour to a blind person who never saw it.

If you're counting page size only on the Gzip version, then you're missing the point. Total bytes downloaded is a metric, but not the only important one. Lots of repeated code makes for absolutely amazing gz compression resulting in very small downloaded bytes, but it still has to be uncompressed, parsed, etc, all of which can have a pretty major impact on devices on the lower end of the capability spectrum. Look at both compressed and uncompressed. It's not an absolute 1:1 match against required processing power on the end users device, but it's a fairly good indicator.

What's the point of measuring uncompressed if the entire internet delivers compressed?
Also, uncompressed Tailwind is also much smaller than the classic Semantic CSS approach.

I feel like you're looking for any excuse to prove that I'm wrong just to prove that I'm wrong without even googling anything about Tailwind. 😂

We measure compressed for transport performance, and uncompressed for performance on lower end devices. If a file is 50kB uncompressed, that's alright (although still very high for something like a blog or personal website), but if it uncomressed to 1MB, then it has a big impact on devices with less power (basically what a huge chunk of the world is using). The bigger the file, the more memory it requires to hold (a low end device doesn't have an unlimited amount of memory), and it requires more processing power to parse, thus leading to longer delays on First Meaningful Paint (FMP), more impact against battery life, etc.

You say I need to Google things before replying, but I feel that you don't actually understand the points I'm making. I understand what you're saying, but your arguments aren't refuting my points, so there's nothing yet for me to "Google".

Tailwind final CSS file (unzipped) is about 10-20 times smaller comparing to traditional semantic CSS approach.

Again, try Tailwind before bashing it.

Tailwind final CSS file (unzipped) is about 10-20 times smaller comparing to traditional semantic CSS approach.

Is it really? That number seems like it might be a wild guess without substantiation. Just by looking at a few sites using it, you can see that most often, the produced files are large (taken from a list of top sites using Tailwind, and Tailwinds own site):

Site Compressed Uncompressed
tailwindcss.com 19.15kB 110.21kB
support.zwift.com 127.85kB 1.84MB
loyalcompanion.com 57.77kB 390.61kB
fri.uni-lj.si 186.62kB 1.84MB
quad.hw.com 127.85kB 1.84MB
holstee.com 95.82kB 694.33kB
dmc-modesto.com 61.5kB 329.36kB
delraymedicalctr.com 61.5kB 329.36kB
wigwamwonderland.co.uk 52.81kB 301.19kB
askfavr.com 113.43 1.02MB

If a websites CSS file is in the hundreds of kB uncompressed, that's not great, but if it reaches MB, then something is awfully wrong.

Now, you could argue that this is just because they haven't got any kind of purge/pruning as a part of their build process, but that same argument could be made of any CSS, it's not a unique thing that only Tailwind has, so it's not a factor. What absolutely is a factor is the default, and as you can see from a couple of these websites that include the default (non custom) Tailwind CSS, the result is in the MB end of the scale.

You can ignore this if you don't know or care about the impact this has on low powered devices (e.g. mobiles, which is what most of the worlds web browsing is performed on these days) but that doesn't actually make the problem go away.

So, you can keep on requesting that I "try Tailwind before bashing it", but I think I have shown that I do understand what I'm arguing. I'm not trying to downplay your own development experience, but I am not wholly certain you understand the point I'm trying to make.

Mate. PurgeCSS is built into Tailwind-css. No one uses Tailwind without PurgeCSS.

Also, that number is coming from my two large projects.

I'm trying to tell that your point is based on false (or lacking) info.

Before bashing anything your should study it.

Ehm. Ashley just provided you exact numbers - so your assertion, that "no one uses Tailwind without PurgeCSS" is already proved to be wrong, before you wrote that. And your main argument is, that Ashley is false because YOU think he hasn't tried it. Thats not an argument for (or against tailwind), thats just bad argumentation style.

I want to pick up one main point in your argumentation:
"The less files you need to edit to make a necessary change - the better your concerns are separated."

If this is true, than tailwind is really bad in separation of concerns. Let's think about a simple example: Lets say we have a website with multiple forms on it. We decide to make all form elements have a grey text color and round corners so we add to douzens of files (doesn't matter if its HTML, Vue, Blade, Twig or whatever) these tailwind classes. Some days later, a designer (or the CI team) decides, that all form elements should be with green text color and without a border.

Now the 1000$ question - how many files do you have to update if you use tailwind? How many if you use for example bootstrap?

And if you are talking about file sizes and performance - CSS (zipped or unzipped) is just one messurment (and tailwind isn't that great in this category either). What about HTML size? Surfing on a website visiting 30 pages of it, I will only download (and parse) the css one time, but the HTML 30 times. So what is smaller and faster:


<button class="bg-blue-500 hover:bg-blue-700 text-white 
    font-bold py-2 px-4 rounded">

Traditional aproach

<button class="btn btn-primary">

May I ask you to watch this 17 min video before making any more false statements?


First of all - this comparison isn't a very good argument for your point. It shows, that uncompressed html with utility-first is just trash. Gzip is worse and only with brotli it is minimal better (0.8 kb).

You also mentioned, that utility first is soooo easy, but it only perform well, if you add extra steps to it, so you weaking your own point.

Second: This comparision isn't fair at all. She compares an "old" version of a side, which grews over time with a completle new created, optimzied version. Its like you would say - hey, my new Honda is much better then my 30 years old BMW.

To be fair, a lot of the arguments in the video are true or some kind of true. But she basically only picks aspects, where utility-first aproach is performing well. The aspects which dont fit well for her point are ignored or she just says "its ugly, but live with it". She also compares more or less "hardcore" sematic vs "utility first" mixed with semantic ("create button classes") and promote it as a feature of utility first only.

I totally understand, that the new kid in the block has to show his muscles, but this "I am the new super hero for all cases and everything what we have done till now is wrong," behavior is just stupid.

Let's just see if it's better than the existing CSS frameworks. Time will tell.


Code of Conduct Report abuse