Tailwind is bad because i don't like it

I've seen this post flung around like it has any valid points about TailwindCss. https://dev.to/brianboyko/tailwindcss-adds-complexity-does-nothing-3hpn

I even had one of my colleagues post this saying he's worried about not being able to help frontend with styles because he doesn't like Tailwind.

So here I'll address all the points Brian made, with actual examples and a bit of logic, and as few opinions as possible.

But first let me address a few general points:

There are lots of posts like Brians, mostly saying that they don't "Like" it and it's their own "opinion", but then going down the road of insulting people for "liking" it or having a different "opinion" to theirs. Or they wrote a post a while back with most of the issues addressed by the team. Some of the posts update their answers, but most don't. Tailwind is still an evolving project. The four people behind it usually have the same problems and not enough time to solve them, but they typically address these points over time.

I sum these posts up like this:

1. It's OK not to like it
2. most of the points they make are their opinion and usually without sound logic.
3. They throw "best practices" and other magical words around like it makes their arguments/points valid. Most "best practices" evolve. Sometimes "best practices" become "bad practices". So it doesn't make anything valid. It's all based on context and situation
4. The ones I've read made "straw man" arguments and usually contradict themselves in the same post. I might be wrong, but I'm yet to find any post which addresses some actual problems with Tailwind.
5. If you're writing static HTML without any js framework, some of the points are valid. But then they argue that Tailwind is suitable for small projects, but not enterprise. This statement contradicts itself. If you're writing a large scale app without using a component framework, you have more significant issues than using Tailwind, and maybe Tailwind is not a good fit for you.

Side note

I've written pure CSS. I've written a component library using SASS and BEM, so don't tell me that I should learn CSS or SCSS. I know them. I've used them.

This is just inline styles with extra steps.

This statement is wrong on so many levels, and he even contradicts himself in the same post when he writes a "solution" in the It's hard to read part, which is not possible to solve with inline styles.

So to clarify, no, it's not like inline styles and if you think that, maybe you don't understand the power tailwind gives you.

He gives an example:
<div class="flex">foo</div> has the same exact effect as writing <div style="display: flex;">foo</div>

Then he discards the whole framework based on this contrived strawman argument. Because anything you can argue against inline styles is the same argument, you can raise against Tailwind.

Well, it's simply not true;

Sure you could write style="display: flex;" but then how you make it responsive class="mx:flex" the short answer is you can't put media queries in inline styles and not just that tailwind abstracts away from a lot of complex classes you would have to write.

Also, Tailwind is utility CSS CLASSES which means you get the full benefits of CSS, cascading, auto prefixing (with build tools), specificity and so forth.

What he does here is:

1. Grabs a contrived strawman example
2. Dismisses the whole framework because of that
3. Then goes on a journey to try and write his own utility framework, but "better" with 'blackjack and stuff'.

I'm not making this up. He is writing a "better" utility framework!!!

It's WET, not DRY.

First of DRY is not as good as people claim it to be. Especially in the frontend, especially with CSS. DRY means tightly coupled.

I tend to write wet components. And only combine them when they seem to keep a consistent API. This, turns out, is a real lifesaver in quite a few cases, as usually they evolved into quite different components, and separating them would become a pain in the butt real quick.

He again raises a straw man argument. ANY MAJOR BRAND STYLE CHANGE WILL REQUIRE WORK. Like it's only applicable to Tailwind...

I don't know what he uses to write his HTML. In the comments, he says he works with React/Vue. I don't understand what he imagines people write their HTML like.

If you're working on anything significant, you will have a component library, and you should be writing code like this:

<BrandButton>Click me</BrandButton>

And not like this:

<button class="lots of tailwind classes here" >
Click me
</button>

Unless you're working with HTML only and have no way of writing components, then sure, his points are valid.

Stupid decisions will require a stupid amount of work.

So basically, he argues that when you only want to replace the buttons, you will have to find ALL the places where buttons were written and replace ALL those classes over millions of lines of code. As you see with an actual example of production-level code will be as simple as changing that one component.

He mentions that you will write bg-blue-500 instead of bg-primary-500, sure if you're braindead and don't have even the slightest idea of how to write maintainable utility classes. Even if you write bg-blue-500, which you agreed is the primary colour.
It's easy to mass search and replace -blue- with -primary- or any other colour. But please, for your own sake, use branded/meaningful names primary brand accent danger are some good examples for colours. You can apply this to other classes.

He mentions that there are more changes when doing a redesign. If you write your components, the right way would be as simple as changing some Brand<Components>. This is as much work as changing the CSS classes.

So again, a strawman argument that is easy to argue. But with any app which uses a framework that supports components. Those points are invalid.

HTML should only concern itself with the structure of your page, not the styling of the page.

Hello, 1990 called, and it wants its best practices back.

He writes:

In other words, your HTML (structure syntax) shouldn't have information about what the styles should be, it should only contain information about the structure of the page.

Sure if you have to write HTML without a framework that supports component

And the answer to that is STYLE COMPONENTS. Seriously it's like he's writing some mythical HTML that doesn't have logic and styling in it.

It's like he imagines that production level apps are writing html like:
Straw man:

<div class="card">
  <h3 class="card__title">Straw man 1</h3>
  <p class="card__body">We all write our code like this?</p>
</div>
<div class="card">
  <h3 class="card__title">Straw man 2</h3>
  <p class="card__body">Don't we?</p>
</div>

Actual production code:

<Point v-for="point in points" 
       :key="point.id" 
       v-bind="point"
       />

where <Point> is a COMPONENT:

<template>
    <div class="rounded-xl border border-brand-400 bg-white">
        <h3 class="text-xl text-brand-400 font-title">
        {{ title }}
        <h3>
        <p class="mt-4 text-brand-200">{{ description }}</p> 
    <div>
</template>

These points are somewhat strange, if not just plain crazy, or just the usual strawman arguments.

Which brings us to:

It's hard to read

This point is an OPINION, not a fact.

Here's the opposite opinion.

Here's an actual example of production level code:

  <PageNew v-bind="page">
    <ConfirmationAlert
      v-if="shouldShowConfirmBookingCard"
      :confirm-booking-path="confirmBookingPath"
      :propose-changes-path="proposeChangesPath"
      class="mb-2"
    />
    <Tabs v-if="stateIs(STATES.IDLE)">
      <DetailsTab v-bind="TABS.OVERVIEW">
        <Overview />
      </DetailsTab>
      <DetailsTab v-bind="TABS.MESSAGES">
        <Messages />
      </DetailsTab>
      <DetailsTab v-bind="TABS.ATTACHMENTS">
        <Attachments />
      </DetailsTab>
      <DetailsTab v-bind="TABS.CHANGE_LOG">
        <ChangeLog />
      </DetailsTab>
    </Tabs>
    <ServerErrorCard v-if="stateIs(STATES.ERROR)"
@retry="fetchBookingOverview" />
    <LoadingCard v-if="stateIs(STATES.LOADING)" />
  </PageNew>

If you know how to use components, this is easy to achieve. And as you can see, there is ONE utility class in this high-level component.

OK, but what if you go deeper. Here's the <Overview> component:

  <div>
    <CargoSummary v-bind="bookingData" />
    <div class="flex space-x-2 mt-2">
      <BookingDetails class="w-1/3" v-bind="bookingData" />
      <SectionCard class="w-2/3" title="Ports & Dates">
        <PortsReview v-if="portsAndDates" v-bind="portsAndDates" />
      </SectionCard>
    </div>
    <PackingListOverview
      v-if="!bookingData.isBulk"
      :packing-list="packingList"
    />
  </div>

Again only simple layout classes here. Which if you understand Tailwind, it is super easy to read and visualize.

Ok, but what if we go deeper? Here's the <SectionCard>:

<div class="pt-8 pb-4 bg-white rounded-lg overflow-hidden shadow">
    <div
        class="px-6 pb-4 border-b flex items-baseline"
        :class="{
        'border-transparent': !border,
        'border-brand-200': border,
        }"
    >
        <div class="flex-1">
            <Title>{{ title }}</Title>
            <p v-if="subTitle" class="mt-2 text-sm leading-4">
                {{ subTitle }}
            </p>
        </div>

        <div v-if="$slots.actions" class="flex-shrink-0">
            <slot name="actions" />
        </div>
    </div>
    <div :class="{ 'px-6': padding }">
        <slot />
    </div>
</div>

That's full of Tailwind, and for me, this is beautiful.
With a bit of mastery of Tailwind, which has great documentation, or the tailwind plugin, which shows what a class does on hover:

This code is trivial to read and see how the styles are affected by the props. And this is my opinion.

Imagine having the same component written like this:

<div class="section-card">
    <div
        class="section-card__head"
        :class="{
        'section-card__head--bordered': border, // you now have to be aware that without this modifier class the border is transparent
        }"
    >
        <div class="section-card__head__title"> // what is a better BEM name here?
            <Title>{{ title }}</Title>
            <p v-if="subTitle" class="section-card__subtitle">
                {{ subTitle }}
            </p>
        </div>

        <div v-if="$slots.actions" class="section-card__actions">
            <slot name="actions" />
        </div>
    </div>
    <div :class="{ 'section-card__body--padded': padding }">
        <slot />
    </div>
</div>

Suddenly you have to come with names for everything.
To understand what is happening, you have to keep switching to the CSS. I don't know Rick, this whole it's easier to read BEM or some classes you've made up seems a bit contrived.

Naming is one of the more challenging problems in programming.
Tailwind has an unambiguous syntax with superb documentation, which means the naming problem mostly goes away.

And granted, this is still hard to read. But let me tell you.

I can catch VISUAL bugs just by READING the pull request.

I could never do this before. Using BEM or any other methodology.
Again this is my personal opinion/experience. So I won't argue it's not hard to read.
But using Components, you have the context of what the classes do, and only your low-level components should have that many classes in them.

And those components are complex whatever you use CSS/SCSS/tailwind.
It's localized complexity.
Whether you use CSS and class names and "simple" HTML, or you use styled-components.
Where you put the complexity is up to you.

But let me ask you which is easier to parse?

:class="{ 'section-card__body--padded': padding }" 

or

:class="{ 'px-6': padding }" 

especially when you can hover over the class and see this?:

Even without the plugin, you can read these classes and understand them.

If you know tailwinds consistent naming p = padding x = means x-axis (left/right) 6 = means 1.5 rem and it means this everywhere, with a few exceptions for the spacing.

These points are just an opinion.
But I'd rather learn something that has exceptionally well-documented API. Rather than writing inline styles or writing my own utilities or BEM.

He then argues:

"const h = 10" instead of "const height = 10"

Tailwind has SIX abbreviations, SOME modifiers and FIVE responsive design prefixes.

ABBREVIATIONS:
m - margin
p - padding
w - width
h - height
z - z-index
bg - background

MODIFIERS:
full - 100%
screen - 100 (vh or vw)
x - x axis, left/right
y - y axis, top/bottom
t - top
r - right
b - bottom
l - left

RESPONSIVE DESIGN:

I think it's fair to say it's not hard to memorize these abbreviations. Most of these are so commonly used that they deserve their abbreviations.

So again, we have a strawman argument against a minor part of Tailwind, which is more helpful than burdensome. We all use a few Abbreviations here and there.

But remember the team is working. They have the same issues, and they will find a way to fix them. So this:

<div
  class="w-16 h-16 rounded text-white bg-black py-1 px-2 m-1 text-sm md:w-32 md:h-32 md:rounded-md md:text-base lg:w-48 lg:h-48 lg:rounded-lg lg:text-lg"
>
  Yikes.
</div>

Might become this in the future:

<div
  class="w-16 h-16 rounded text-white bg-black py-1 px-2 m-1 text-sm md:(w-32 h-32 rounded-md text-base) lg:(w-48 h-48 rounded-lg text-lg)"
>
  Yikes.
</div>

And In a framework where it allows backticks, you can mitigate this now:

<div
  :class="`
w-16 h-16 rounded text-white bg-black py-1 px-2 m-1 text-sm 
md:w-32 md:h-32 md:rounded-md md:text-base
lg:w-48 lg:h-48 lg:rounded-lg lg:text-lg
`"
>
  Yikes.
</div>

Again for some classes, you might want to write custom CSS. I'd argue against it. But it's up to you.

You lose a lot of the features built into standard CSS

At this point, I think he loses it a bit, as most of those features are available in tailwind documentation Hover, Focus, & Other States
I think this covers about 90% of use cases for those features.
And anything that requires something more complex goes into custom CSS. Remember it's still an option? And no, you don't need to use @apply.

It solves a problem that doesn't exist.

Some points here are valid, but they are valid for any other framework, even for custom CSS.

At least with Tailwind, it's not super complex to align it with your design system. And in the case it "dies", it's possible to take the project and maintain it, which is just as hard/easy depending on your team for your custom CSS.

At least with Tailwind, you're standing on the shoulders of Giants.
The documentation is superb.
The base work is done.
It's showing no signs of stopping.
It's an open-source supported by developers who use it for their own complimentary paid products.

This looks like it has a lot more possibility of staying alive than some other frameworks out there.
They built a fantastic open-source framework and are making their products based on the open-source work.

You're being disrespectful to the people who like Tailwind.

Here he contradicts himself literally in the same point and the next.

He writes:

My thesis is not, as you seem to think, "I don't like Tailwind, and therefore YOU shouldn't like Tailwind either". That's a 12 year old's viewpoint of technology criticism.

AND LITERALLY THE NEXT SENTENCE:

He writes:

Rather my thesis is: "If you choose Tailwind for a mission-critical application, you will end up making your job harder, your application more brittle, and your team, in the long-term, will suffer."

ALL based on his opinion.

He made a lot of strawman arguments.
He jumped hoops to show you and me the errors of our ways.
All of this sounds like this:
"My opinion is absolute, and you will suffer for not honouring it. You are foolish in your ways. Only I see the true path forward".

But CSS has massive problems!

He just lost it completely here, and those were some bold claims when he provided no unopinionated arguments.

Every argument in his post was a straw man.
Those that were not, apply to any framework, even custom CSS.

He proclaims that he is right, and anyone and everyone who is using Tailwind is a braindead moron who "starts hammering in nails with the butt end of a loaded revolver (Tailwind)."

A few benefits of Tailwind that he conveniently missed out

1. Tailwind JIT builds super fast and a super slim CSS file with only the utilities you need in a single global CSS file.
2. The exceptional documentation
3. The framework is evolving and making even the most complex points invalid as we speak
4. It's super customizable. Anything and everything is documented and customizable
5. Speed of development
6. Being able to "SEE" the components just by reading the HTML
7. Size of the final CSS file.

-- Edit 10th May 2021 --

1. Constraining css to a specific set of predefined rules following a design system, and added UI consistency even if you don't have a design system. - Thanks to @akryum

Look, it's OK if you don't like it.

Sure Tailwind is not for everyone.
Sure it has it's issues.
But those issues are persistent everywhere.
And people are working out ways to fix them.

BUT do not assume everyone who uses it is a moron who "starts hammering in nails with the butt end of a loaded revolver (Tailwind)."

You, sir have only provided opinions and hung up a lot of straw men. And you dare to claim that your view is something more than that.

A lot of people use it every day and reap the benefits.
No extra complexity.
No extra obscurity.
No need to come up with complex BEM naming architectures.

Which you might not be able to reap, based on your context and/or circumstances. And it's OK don't use it. But do not string up strawmen and opinions to bring other people down just because you don't like it.

Thank you for reading. Have a nice day.

Comments

[Kerry Boyko]

Nice rebuttal. I disagree obviously but you make your case well. Going to link this in the original article.

[Josh]

This is by far the classiest response to this article that I think could have been made. There are places where, in your original post, you make anecdotal comparisons between Tailwind users and some other kind of (much more obviously) bad idea, and I can understand why Tailwind users would take offense to such comparisons.

But they're comparisons being made to illustrate informatively, whose subjects are unfavorable ones to be compared to; this rebuttal post flat out declares you an idiot for some of the arguments you make and mocks you for trying to build a better CSS utility framework. The rhetoric goes from inflammatory to downright incendiary, and I don't know that I would've had the composure to still say "You make some good points," personally.

If this site had an equivalent of Reddit Gold, I would give it to you now. Or better, if I can buy you a KoFi, you absolutely deserve it

[Kerry Boyko]

I came to programming through a long and winding path including through journalism and political activism. I've long since learned that trying to convince someone opposed to your view that you are right and they are wrong doesn't get anywhere.

It is far more productive - and rewarding - to get your opposite to think more clearly and deeply about their own argument. If there are flaws in my argument, criticism points them out, if there are flaws in their argument, criticism lays them bare.

[Mykolas Mankevicius]

Look if you mock people for using a tool, and then go on to write that same kind of tool but "better", i will mock you for it, untill you actually do it, and if you do. i will eat my own words won't i?

Not in a single place i have called Brian an idiot.
Please point any place that does it and i will add an edit to clarify those sentences.

What i've done is call his points strawmen, which they were. And those that we're not are applicable to any other tool dealing with css.

Which in no point attacks Brian personally, it attacks his points/opinions.

I even said that if you have certain circumstances, then his points/opinions are valid.

And I hope Brian saw it that way too. Otherwise i've done a horrible job. I can only add clarifications now.

[ecyrbe]

Listen, you wrote this He just lost it completely here.

This is not the way to make a constructive article.

[Charlie J Smotherman]

TailwindCSS is nothing more than another tool in my tool box.

Sometimes its the exact tool I need sometimes it's not.

Context and situation.

[Stanislav Ø.]

The thing is frameworks are more like a building material than tools. A tool is something, that can be switched easily without messing with a product you make with that tool. Replacing a regular screwdriver with an electric one changes your productivity and doesn't require rebuilding your walls. Choosing a wrong insulation material will get you into a lot of troubles if you want to replace it.

[Simas Butavičius]

Thanks for great examples of real-life usage of TailwindCss!

I could see Brian's points as valid in the context of developing wordpress theme, which had me writing a lot of vanilla html + css with no great framework to encapsulate and re-use components. Maybe I just don't know a good way to do it, especially when you have to integrate with 3rd party plugins such as woocommerce.

Trying to juggle all the 3rd party classes, overriding them and trying to be DRY (as in not to rewrite all woocommerce templates for cart, product listing etc), also in keeping with wordpress standards simply left no place for TailwindCss which would bring more confusion to the table where each element has 5-10 "semantic" classes applied by woocommerce just in case.

This whole experience threw me back in time where "separation of concerns" is maybe a greater value and helps with readability.

Mykolas' example of using TailwindCss with frameworks that let you define and reuse components in very elegant manner (React etc.) also make perfect sense, and most of Brian's points against TailwindCss are not really a concern in a more modern codebase. I am ditching my wordpress theme and building a NextJS (React)+TailwindCss frontend and keeping WP+Woocommerce as a backend only. In this scenario, Mykolas' arguments make perfect sense.

I don't agree that Brian's points are all strawmen. They are one-sided maybe, but that's his opinion and I think a lot of readers could relate, especially if they're dealing with older code.

This clash of opinions makes me think - if you're dealing with problems that Brian brought up, maybe it's time you rethink tools you're using. If you have to manually crawl code to change some color in lots of places, it's not a question of CSS/SASS/Tailwind at all.

However, if you have no choice of technology to use or have to adhere to some standards or requirements where Brian's points resonate with you, probably TailwindCss will not make you life easier.

It's surprising how quickly we can go "all in" in these discussions :)

[Mykolas Mankevicius]

Ahh i can see the other side of things now. Had no idea that people with wordpress/woocomerce/older cobases have these issues. I've been lucky enough to only ever have worked with more up to date tools. I can see why this would be a big issue with tailwind in this case.

But like i mention in the post, i've said if you can't use it don't it's not the be all, end all.

[Mark N. Amoin]

I've been a developer for quiet a while. Sad to say I find Tailwind too tedious, laborious and grueling to implement. It's too dirty on the markup and you're forced to create markup components even when there's no need for it. And in doing that, you risk importing components which takes too much time, making the overall development experience very slow.

I also find its performance a bit slow for some reason. Perhaps maybe there's too much WET class items repeating over and over again in a single page? I'm unsure how their tree shaking mechanism works in this area.

In the meantime I'm sticking to Bootstrap until I see some overall workflow improvements from Tailwind.

[Mykolas Mankevicius]

Not sure what you mean about performance. As bootstrap will import all of its css. Tailwind only generates the classes that are used in your markup so you have 100 places where you use 'pt-10' you will only have one class in your css. Overall the css bundle is very small compared to anything else. You don't need to write css manualy and scope it or somehow else maintain it :)

But like i said you can use whatever you prefer and are productive in, just don't tell people they are stupid for using a tool. Which is what the original author of the post i'm rebuking implied.

[Tinotenda Muringami]

Massive respect to my man out here using Bootstap over tailwind in 2023 🙌

[Maxhou]

So to clarify, no, it's not like inline styles and if you think that, maybe you don't understand the power tailwind gives you.

He gives an example:
<div class="flex">foo</div> has the same exact effect as writing <div style="display: flex;">foo</div>

I don't get your point, yes the example is exactly same with writing inline style and it's even write in the first page of tailwind's documentation

Why not just use inline styles?

A common reaction to this approach is wondering, “isn’t this just inline styles?” and in some ways it is — you’re applying styles directly to elements instead of assigning them a class name and then styling that class.

Tailwind is good for people who never understand how to use CSS otherwise it's a really pain to see what it does. The original post is right on every point he mentionned

[Mykolas Mankevicius]

You took one sentence and built a straw man around it, here's the full explanation from this post, if you've bothered to read just a few sentences down:

And i don't want to assume but your english seems to be a barrier here:

A common reaction to this approach is wondering, “isn’t this just inline styles?” and in some ways it is — you’re applying styles directly to elements instead of assigning them a class name and then styling that class.

in some ways it is means that it looks like inline styles a little, but tailwind has much more power on top of that.

Tailwind is good for people who never understand how to use CSS otherwise it's a really pain to see what it does. The original post is right on every point he mentioned

I've written a stylable component library from scratch using pure CSS. I've used CSS extensively before Tailwind. Saying that i never understood how to use CSS is a very big assumption from your part, and it's very wrong...

And if you've read the full post you'll see how i've debunked every point apart from opinions, but opinions are not facts, and there are at least as many opinions as there are people. Just because you like some ones opinion, doesn't make it right.

[Maxhou]

You took one sentence

No, it's just not worth and make it less easy to read to quote the entire paragraph. You know I was talking about the all paragraph.

and built a straw man around it

You seem really obsessed of it and even miss you are doing the same thing through your entire post.

in some ways it is means that it looks like inline styles a little, but tailwind has much more power on top of that.

It means what it means. Don't try to change it on your way. It means "yes it's similar to inline styles". It's not because you paint your banana in blue that means they are not banana anymore.

Fortunately tailwind has more power on top of that, if not why people would be interested of it ? But it doesn't change that you are giving bad habits to developer and at the end Tailwind isn't better than css

I've written a stylable component library from scratch using pure CSS. I've used CSS extensively before Tailwind. Saying that i never understood how to use CSS is a very big assumption from your part, and it's very wrong...

And ? Doesn't legitimate any of your saying and honestly build component library doesn't mean you know how to use CSS or HTML, you don't need to debug a page which multiples component or taking care about optimizing accessibility, SEO, etc ... .

So many tailwind components are missing some basic rules of html, by using only div/p instead of the correct tag, missing accessibility attribute, not taking care about the readability of it etc ...

An easy example in the Tailwind documentation (again) where they think it's better to replace a subheading tag by a div.

If you can't understand the importance of it, then maybe you should return to learn HTML or CSS instead of learning tailwind, would be more useful.

And if you've read the full post you'll see how i've debunked every point apart from opinions, but opinions are not facts, and there are at least as many opinions as there are people. Just because you like some ones opinion, doesn't make it right.

I hope you are reading what you write ...
You are just doing the exactly same thing with the original post but because it's YOUR opinion you things it's more valuable than others on.

From the beginning of your post to then end, and from the beginning of your answer to the end, you are doing exactly what your criticize.

My initial post didn't mean to be aggressive but there is no way to debate with someone like you.

[Mykolas Mankevicius]

No, it's just not worth and make it less easy to read to quote the entire paragraph. You know I was talking about the all paragraph.

Ok, so how tell me how would you do md:flex hover:underline with inline styles? How is this a strawman from my side, please i'm interested?

You seem really obsessed of it and even miss you are doing the same thing through your entire post.

Please tell me where i've created strawman examples? I really don't see it, i gave real life examples from real projects. Not just some made up ways people would write it using any framework which has a concept of components? Which i explicitly mentioned a few times in the post. If you're writing without ability to use components then i agree tailwind might not be for you, which again i mentioned in the post...

But it doesn't change that you are giving bad habits to developer and at the end Tailwind isn't better than css

What bad habits? Tailwind isn't better than CSS, tailwind is a way to use CSS, like BEM or SASS it's different from other ways, but it's still CSS don't see what your argument is here?

And ? Doesn't legitimate any of your saying and honestly build component library doesn't mean you know how to use CSS or HTML, you don't need to debug a page which multiples component or taking care about optimizing accessibility, SEO, etc ... .

What is your argument here? This applies to the accessibility practices, SEO, etc... none of which has anything to do with writing CSS. CSS doesn't magically solve these things for you? Using the right semantic tags, aria attributes and so on has nothing to do with Tailwind, why are you blaming it for that?

If you can't understand the importance of it, then maybe you should return to learn HTML or CSS instead of learning tailwind, would be more useful.

How is this not aggressive from you? CSS and using the correct HTML tags/attributes has nothing to do with each other. You gave the argument:

People who use tailwind don't understand how to write CSS.

I gave a counter argument:

I know how to write CSS, because i've used it extensively to solve complex components and styling"

Instead of accepting my counter argument, you've moved the goalpost and made a new argument:

So many tailwind components are missing some basic rules of html, by using only div/p instead of the correct tag, missing accessibility attribute, not taking care about the readability of it etc ...

This is a whole new argument, and again you assume that i don't know these things? What components are you talking about? From the documentation? Because Tailwind UI and Headless UI has all these things and more. With correct semantic tags, with screen reader only texts again from the docs. And even if they didn't writing correct HTML it's up to the developer. Tailwind has classes to help you, but it can't force you to do it. But this is a completely different argument, which has nothing to do with Tailwind or CSS...
What is your point?

If you can't understand the importance of it, then maybe you should return to learn HTML or CSS instead of learning tailwind, would be more useful.

That is just condescending... Like the way you finished your first reply "People who use Tailwind don't understand CSS. Hence why i'm a bit angry...

I hope you are reading what you write ...
You are just doing the exactly same thing with the original post but because it's YOUR opinion you things it's more valuable than others on.

The initial post doesn't point out that it's just THEIR opinion and they show their opinion as Fact. I've written multiples times in my post, which of his points are opinions and gave counter opinions. In those cases i say that it's an opinion and try to provide examples of why i have these opinions, and ask people (leading) questions as i am biased. But i've not masqueraded my opinions as facts, i've pointed them out. And plenty of times i give an example where his opinions carry weight and for what reasons.

From the beginning of your post to then end, and from the beginning of your answer to the end, you are doing exactly what your criticize.

But you're doing the same, so when in Rome...

My initial post didn't mean to be aggressive but there is no way to debate with someone like you.

Well the way you ended your first post sure doesn't sound condescending:

Tailwind is good for people who never understand how to use CSS otherwise it's a really pain to see what it does. The original post is right on every point he mentionned

There is plenty of ways to argue with me, but please show counter arguments to the examples i gave.

I don't get your point, yes the example is exactly same with writing inline style and it's even write in the first page of tailwind's documentation

Here I'll give you a question how would i do something as simple as hover:underline or md:flex or sr-only sm:not-sr-only with inline styles?
Hint: you can't...

So your argument is invalid straight out of the box and simply shows you don't understand what Tailwind does.
Your new arguments "Tailwind docs doesn't show you how to write aria attributes or how to optimise SEO". It's not Tailwinds problem, Tailwind doesn't claim to solve these things. Although TailwindUI components come with aria attributes and accessibility considerations. You say Tailwind doesn't do these things, but please tell me what CSS framework optimises your SEO? This is what i call strawman arguments, which is what i point out. Contrived examples of non-existing situations (at least not where you can use components), or argument that simply have nothing to do with the framework in question.

Give me actual examples to argue and i'll try my best to argue them. Opinions are just that opinions. I've pointed this out in my post a few times, and i'm not saying my opinion is the right one, i'm letting you to choose what is best for you, by pointing to examples of code you're most likely writing...

His post did the same, he showed arguments which:

1. Apply to any way you write CSS.
2. Have nothing to do with Tailwind at all.
3. Shows contrived examples of how you would write html/css code. where in reality if you use a framework which has components would not exist, like i've showed with examples of real code.

And like i mentioned in the post, it's ok not to like it, it's ok not to use it. But if you're saying Tailwind is bad, or it gives developers bad habits. Then defend those opinions with facts/examples of real code. Show me better habits, better ways of writing CSS/HTML with actual real world code that you would use in a project using React/Vue/Svelte/etc...
Show me how would you refactor/maintain those examples?
Show me how would you avoid producing tons of duplicated CSS?
Show me how would you avoid cascading issues over multiple components?
Show me how would you ship only the css that your codebase is using?
Show me how to avoid context switching between html layout and writing styles for those layouts?
Show me these things that Tailwind gives you, with amazing documentation, amazing plugins, customisability, knowledge retention over different projects.

So telling me there's no way to debate me, when you've not given any examples or alternatives or actual arguments, is an easy escape isn't now?

[Mykolas Mankevicius]

And no answer...

[Maxhou]

Don't take a no answer as a "I was right, he was wrong"

I don't answer because you are not here for a debate or you probably try to be as much offensive as you can for hiding silly arguments. So I won't waste my time with it.

[Mykolas Mankevicius]

I'm giving you concrete arguments, questions. Is that not a debate?
Am i being offensive, by trying to clarify things?
But you're right it's ok to disagree and there isn't much point in arguing :)
Have a nice day :)

[Kristian Dupont]

Of all the criticisms you can make of Tailwind, being only "good for people who don't understand CSS" seems the silliest. You obviously need to know how CSS works as it's a paper thin abstraction.

And to the other point, as this article points out, a critical difference appears as soon as you try to use media queries, which is impossible with inline styles.

[Mykolas Mankevicius]

Ok step by step now @bananica :

1. I've mentioned BEM, i didn't say it's good.
2. Burden of Proof Fallacy: This occurs when someone makes a claim but then insists that the other person must prove the claim false rather than providing evidence to support their own claim. In this post i've provided the proof of my opinion and why i like it. I only claim it as better for me. I leave the decision to you. You just said read html spec and what and how it should be used "correctly" but you've not pointed anything out.
3. Write CSS the way it is intended is something "new" that i have not tried. You are assuming that you know anything about me and what i have and have not tried? TailwindCSS is a way to use CSS. I've tried other ways, didn't love it. Thanks for the offer though.
4. HTML is used for sending text over the wire. You got me here, well done.

I have WWW under my fingertips and i came to my conclusions from my experience of using it, and creating websites/apps/games for it. I'm sure you came to yours the same way, it's ok, don't be hurt that not everyone shares your opinion. ;)

[Rowe Morehouse]

I love your article and argument, it's well written and thoughtful, but can you put a TL;DR at the top or bottom to summarize your argument in 7 bullet points, dawg.

PS: I agree with you.

… also, you've seen this, right? :: sancho.dev/blog/tailwind-and-desig...

[Guillaume Chau]

A very important benefit you forgot in the list at the end is constraining css to a specific set of predefined rules following a design system. (And added UI consistency even if you don't have a design system.)

[Tinotenda Muringami]

Deep down every dev that has worked on a semi-complex team project (not a toy hello world project) knows tailwind is a great tool.

[Džuris]

If you accuse the original article of strawmaning, you should beware of the same trap.

You don't do :class="{ 'section-card__body--padded': padding }" in a component. Most of the time you don't need BEM when working in a component. You just have :class="{padded}" and a small <style> block underneath in the same file that contains .padded { padding: var(--spacing-lg); }. And that's it. Clean, readable, consistent.

[Mykolas Mankevicius]

Ok let's change it, and for the sake of your argument keep it simple, the class is in the component style.

<div :class="{ 'padded': padding }"></div>

First you have to come up with a name padded.
When on comming back to edit this, you have to find out what it means.
Now you have to scroll down/search and find this class in the component;

<style>
.padded { 
  padding: var(--spacing-lg); 
}
</style>

Even now you don't know what this means. it could mean anything 0 10px or 10px or 10px 0 or even 1px 2px 3px 4px

So you have to find another varianble (which you had to name) --spacing-lg and only then you see what it means.

So:

1. You have to do a lot of jumping around to figure out the actual meaning.
2. You have to come up with meaningfull most likely undocumented names.
3. You have to be carefull with reusing this class in the same component.

And there are more issues.
What this class is defined globally?
What if this class depends on a parent class?
What if you only want to change the spacing here?
What if you reused this class in the same component? (Remember i've pointed out that this is quite a simple component, How do you change it only in one place?

You see how much more work that is, rather than seing px-6 and if need be updating it to p-6 because the design changed?

And maybe for you it's Clean, readable, consistent. and you're fine to live with that complexity. For me it's all over the place, so not clean. Not readable since you have to jump around to actually read it. and not consitent as you might use padded here and another class in a different place. You can even be lazy and just add extra things to the padded class. So i personally don't see any of that Clean, readable, consistent. in your proposed solution.

What Tailwind does here, is solve all of those issues:
.px-6

1. Means the same everywhere.
2. With a plugin you can see the meaning right there, without it you can search the documentation.
3. Re-usable you can reuse this all over the place knowing it means the same. And yes it will be more verbose as you will need more classes to achieve more intricate designs. But the above arguments still stand.

And sure you might not see it the same way. So we can agree to dissagree what is more Clean, readable, consistent.