DEV Community

Mykolas Mankevicius
Mykolas Mankevicius

Posted on • Updated on

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>
Enter fullscreen mode Exit fullscreen mode

And not like this:

<button class="lots of tailwind classes here" >
Click me
</button>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

Actual production code:

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

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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:
Example in vs-code

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>
Enter fullscreen mode Exit fullscreen mode

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 }" 
Enter fullscreen mode Exit fullscreen mode

or

:class="{ 'px-6': padding }" 
Enter fullscreen mode Exit fullscreen mode

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

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:
Alt Text

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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.

Discussion (14)

Collapse
brianboyko profile image
Brian Boyko

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

Collapse
thepeoplesbourgeois profile image
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

Collapse
brianboyko profile image
Brian 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.

Collapse
neophen profile image
Mykolas Mankevicius Author • Edited on

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.

Thread Thread
ecyrbe profile image
ecyrbe

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

This is not the way to make a constructive article.

Collapse
cjsmocjsmo profile image
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.

Collapse
rowemore profile image
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...

Collapse
akryum profile image
Guillaume Chau • Edited on

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.)

Collapse
tontonsb profile image
Džuris

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.

In practice there are two problems with these. First off, bg-primary-500 means there's still 10 or so variants. Normally I would only want a couple at most, the rest only make room for inconsistencies. That's why I prefer having a single file of CSS variables where all the available colors are defined and the palette is kept to a reasonable minimum.

Secondly, all that formatting is hardcoded in the markup. For example, there's the Jetstream and Breeze frontend packages for Laravel. And the styles for all the components are defined within those components. If I want them to comply with my stylesheet I can't just update .btn.btn-primary and .form-control like we can in CSS kits. You have to either go into all of the components and change them or you have to change what .text-red-600 does. But what if another package has defined a similar button with .text-maroon-700? Do you redefine .text-red-600 and .text-maroon-700 to both be light orange?

Collapse
neophen profile image
Mykolas Mankevicius Author
  1. bg-primary-500 means there's still 10 or so variants - you can limit it to whatever is good for you, that's what the config is for, you can disable all colors and only have the ones you need in your design system.

  2. All that formatting is hardcoded in the markup. - You are correct, and this is an actuall problem with Tailwind and themes. I don't think tailwind is well suited for packaging, which is mean to be re-used and customized. The tailwind UI, is a perfect example, you will have to change the classes to match your config/style and make your own components out of them. They provide Vue/React and some other framework, but it will require work to match your design.

Collapse
neophen profile image
Mykolas Mankevicius Author

But what you have done here is move the goalpost.

Neither me nor Brian talked about using external themes/components.

And i still think this is just as difficult with themes/components. Because you have to understand/find the classes. And while it's fine for something like button. It becomes much more difficult to manage, the more custom things you want with the theme/template/components.

At least with jetstream you can see all the components and see how their styles need to change.
Also you know you can search within specific folders right?
What I would do in this case is change the -red- with -primary-. Jetstream doesn't have that many components.
And then if you add another package you do the same change there.

What you do not do is change the meaning of -red- or -maroon-.

You say just change .btn.btn-primary why is that better than just change XButton.vue component.

Collapse
tontonsb profile image
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.

Collapse
neophen profile image
Mykolas Mankevicius Author • Edited on

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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.