DEV Community

Cover image for Tailwind isn't the answer
Madi Ostoja
Madi Ostoja

Posted on • Updated on

Tailwind isn't the answer

Tailwind CSS has taken the frontend development world by storm over the last few years. A utility-first library of CSS classes, it promises a new way of styling that's more consistent, maintainable, and faster than writing CSS directly. And for the most part, it delivers on that promise.

By using Tailwind you're almost guaranteed a single source of truth for all the values you use throughout a project. From typesets to spacing to colours, everything is defined in a single place. Which means that your code stays consistent and you aren't making things up as you go.

This was Tailwind's biggest idea, and the greatest benefit of utility-first CSS as a concept: compose don't create.

Tailwind achieves this with an extensive library of CSS classes to style everything. The idea being that you no longer write any CSS of your own, you compose predefined classes like lego pieces for every single property.

Developers new to this way of working often have a knee-jerk reaction just from looking at example code.

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
 Button
</button>
Enter fullscreen mode Exit fullscreen mode

There's no denying that Tailwind is hideous. Its creator acknowledges as much right on the project home page. But that's just pedantry, and if the Tailwind way of doing things really was the panacea to all our problems then it would be a very small price to pay.

The Problem

The problem with this approach isn't that its ugly, or bloated (Tailwind purges unused classes), or that "you might as well write inline styles" (you shouldn't). It's that in order to apply a consistent set of values with classes, you also have to create classes for every conceivable set of rule:value pairs in CSS, even where it adds no value at all. So you end up using classes like .block rather than writing display: block and .text-center rather than text-align: center.

Of course you can mix Tailwind's more useful classes with regular CSS. But then you're breaking the Tailwind style-by-classes abstraction, and you have to maintain two seperate styling touchpoints for every element.

"So what?" you might ask, what's wrong with just using those classes rather than CSS? It certainly saves some keystrokes. Here is where Tailwind introduces new problems it shouldn't have to solve in the first place.

Reinventing CSS

Tailwind has to reinvent everything regular CSS can already do. Media queries, pseudo elements, selectors, and states. All of it now has to fit into the classes-only paradigm.

Tailwind achieves this with what it calls modifiers. By prepending Tailwind classes with md: they will only apply above the md breakpoint. By appending hover: a class will be applied in a :hover state. And so on.

Each of these tools is a poor facsimile of the functionality gaps it has to fill. Want an :nth-child or ~ sibling selector? Back to CSS. Want to target the devices between two breakpoints? Back to CSS. Want to target children of an element? Back to CSS. You get the picture.

Of course you can go back to CSS to do any of these things. Lovingly coined "bailwind", almost every project will need at least a little custom CSS when Taiwind's classes and modifiers just don't cut it. But then you're back at breaking the Tailwind abstraction, and giving yourself maintenance headaches.

And if this is already a given, then why use pointless classes like block when it adds no consistency or maintainability value over writing display: block in CSS, other than a few saved keystrokes? Because while gap-filling classes like this don't add value, they do add a new Domain Specific Language (DSL) to learn on top of the CSS we all already know.

Class soup

The thing every critic of Tailwind yells at first, its enormous class strings. Yes, they're ugly, but who cares. The problem isn't a surface-level developer perfectionism one. It again comes back to modifiers.

Every rule that applies to a modified state needs its own class with its own modifier. Unlike in CSS where these states and pseudo elements are naturally organised into logical blocks, Tailwind's modified classes can very quickly become a huge, difficult to maintain mess that has to be carefully teased apart line by line.

Take a contrived example of the button we had in the intro of this article, with an icon of some sort added to a ::before pseudo element, and less-than-ideal attention given to class ordering.

<button class="relative before:absolute bg-blue-500 hover:bg-blue-700 text-white before:left-2 font-bold before:text-sm py-2 px-6 rounded  before:top-1/2 before:content-['\f00c']  before:-translate-y-1/2">
  Button with icon
</button>
Enter fullscreen mode Exit fullscreen mode

Of course in this particular example the icon would be better placed as a real element inside the button, but the point stands. Without (and even with) careful ordering of classes, these jumbles very quickly become a maintenance nightmare.

JIT to the rescue?

Tailwind's new Just In Time mode compiles just the classes you use on the fly, rather than pruning back a goliathan stylesheet after the fact. It allows you to use modifiers everywhere out of the box, and most importantly write arbitrary values right in Tailwind classes, like margin-[100px].

This is another language feature that was added to Tailwind's style-by-classes DSL in order to fix problems it introduced itself. And while arbitrary values mean you don't have to break out of Tailwind's paradigm as often, they also diminish the core value that Tailwind provides — a single source of truth for a whole project. Taken to its logical extreme Tailwind JIT is really just reinventing CSS, bit by bit.

The Solution

As I said at the very beginning, Tailwinds' central idea is a very good one — a low-level, utility-driven design system to get rid of magic numbers and bring consistency to your CSS. The problem was the implementation.

Thankfully CSS now has the same solution as every other language to consistent values: variables. CSS variables, or more properly CSS custom properties, are fairly new to the language but already adopted by every major browser, and used extensively in Tailwind's own internals.

For example, Tailwind's .p-4 padding utility could be rewritten like this

:root {
--p-4: 16px;
}

.button {
  padding: var(--p-4);
}
Enter fullscreen mode Exit fullscreen mode

And since we no longer have to write separate classes for every rule:value pair, we can greatly simplify our utility-first design system. We could have one set of size variables that can be applied to any part of padding, margin, width, height, position, etc. Without needing separate utilities for every combination of every property.

:root {
  --size-2: 8px;
  --size-4: 16px;
}

.button {
  padding: var(--size-2) var(--size-4);
  margin: var(--size-4) 0;
}
Enter fullscreen mode Exit fullscreen mode

And since variables are part of the platform, they have a native runtime. We can interact with CSS variables using Javascript, and update them dynamically. This makes things like reskinning a whole interface for dark mode possible with just a couple lines of code, without introducing any new utilities or tools.

function enableDarkMode() {
  document.documentElement.style.setProperty(`--color-background`, `black`);
  document.documentElement.style.setProperty(`--color-text`, `white`);
}
Enter fullscreen mode Exit fullscreen mode

So why don't we, instead of reinventing the styling paradigm altogether, just abstract all the values in an interface into a single source of truth by putting them in CSS variables that can be used anywhere, in regular old CSS, without all these new problems?

By Example

GitHub logo peppercornstudio / pollen

Utility-first CSS for the future

Pollen


Pollen

Utility-first CSS for the future

Introduction

Version Size

Pollen is a standards-driven alternative to Tailwind. A micro-library of CSS variables, it encourages consistency, maintainability, and rapid development. Use it from prototype to production, as a utility-first foundation for your own design system.

What it looks like

Pollen's low-level variables can be used to build any design. They work anywhere and don't require a buildstep or class naming conventions. They're easy to extend and globally responsive, without introducing preprocessors or new syntax.

.button {
  font-size: var(--scale-00);
  font-weight: var(--font-medium);
  padding: var(--size-2) var(--size-3);
  background: var(--color-blue);
  border-radius: var(--radius-sm);
  box-shadow: var(--elevation-2);
  color: white;
}
Enter fullscreen mode Exit fullscreen mode

Documentation

Read the full documentation at pollen.style

Pollen is a standards-driven CSS library that came from this line of thinking. It takes Tailwind’s core ideas and reimplements them as a 0.85kb collection of plain CSS variables. It can deliver all the key benefits of Tailwind without reinventing how we write CSS, thanks to the tools we already have in the web platform. Since it’s just plain CSS it can be used anywhere in any context and in any way.

But you might not need it

Full disclosure: I wrote Pollen. But I'm not trying to sell you on adopting it. I'm trying to sell you on the ideas behind it for your own work.

Pollen is just a collection of hopefully useful CSS variables, translated from Tailwind. But If you already have a solid design system with sizes, typesets, colours, and the other shared values of an interface, then you probably don't need Pollen, and you certainly don't need Tailwind. Write them in one place as CSS variables, and use them everywhere. That's the way out of this insanity.

Bring consistency to CSS by getting rid of magic numbers with variables. The other problems of CSS (deep composition, leaky inheritance, performance optimisation) aren't solved by Tailwind, nor by CSS variables. But they are made harder by the new DSL Tailwind introduces. At least by sticking to regular CSS you have all the other patterns and tools we as a community have been working on for the last decade at your disposal, without any gotchas.

Discussion (113)

The discussion has been locked. New comments can't be added.
Comments have gotten pretty spicy, and I don't think much valuable discussion is happening any more. See my comment for reiteration on some of the concerns raised.
Collapse
gangsthub profile image
Paul Melero

Once again, if you don't like X technology, don't use it. But you don't need to look down on it. If you've created a library with a new paradigm, why not focusing more on the possitive side of it?

Collapse
madeleineostoja profile image
Madi Ostoja Author • Edited on

I literally opened the article praising Tailwind’s core ideas, and how it solves some real problems. But I also think it has some real issues that many people might not consider until they’re maintaining projects at scale with it. If Tailwind fits your use case then go for it, it’s a solid library by some clever people

Collapse
lumsdendigital profile image
Ruaidhri Lumsden

Well said Madi. Thanks for the article, I'll certainly keep this on my reading list in case I do come up against your started issues.

Personally, so far, I love using Tailwind. I just find being able to do my CSS within my markup to be great for productivity, but doesn't feel like 'cheating' because I feel like I still have to understand all of the CSS that it's applying.

I also don't mind having to break out of the abstraction to do some custom CSS in specific cases - for me I don't particularly mind having a long list of utilities such as mt-3, border-2 etc - if it keeps that basic stuff from creating one or, perhaps multiple, large CSS files. It keeps what is in the custom CSS more focused.

Like I said, I haven't really felt like it's limited me so far, but I'll keep this post in mind if I ever feel like it does!

Collapse
sgarciadev profile image
Sergei Garcia • Edited on

Because attacking the leading competitor is the easiest way to pitch something new. Conveniently enough, the author left out any any mention of cons & issues Pollen has over Tailwind. Or how it reintroduces decades old issues traditional CSS codebases have dealing with writing semantic CSS class names, organizing CSS, and handling specificity issues.

But yeah, this was a weird, if not cheap way to introduce Pollen.

Collapse
madeleineostoja profile image
Madi Ostoja Author • Edited on

Hey I really don’t know why you have this axe to grind. For a start nothing about using CSS variables implies needing semantic CSS class names, how you should organise CSS, or deal with specificity. There are so many solutions out there for all of those issues, and variables work in all of them. It is literally just CSS.

And as I have said maaany times, you absolutely don’t need to use Pollen, it isn’t some crazy new framework. It’s literally a collection of CSS variables. If you find it useful then awesome, but what I’m trying to get across is that the platform already has a solution to the value tailwind provides, and the style-by-classes abstraction introduces a lot of difficult problems that often don’t become apparent until you’re using it at scale.

Sorry you didn’t find it helpful.

sgarciadev profile image
Sergei Garcia • Edited on

You can't expect people to not elaborate on the important details you omitted.

For a start nothing about using CSS variables implies needing semantic CSS class names, how you should organise CSS, or deal with specificity. There are so many solutions out there for all of those issues, and variables work in all of them. It is literally just CSS.

Using CSS variables might not imply it, but moving away from a utility-first CSS paradigm like Tailwind's absolutely implies you now need to worry about that. Yes, there are many "solutions" to these issues, but they are far from a silver bullet that magically makes all problems go away. Writing semantic CSS class names will still be hard, CSS code duplication will still be a challenge, and you'll still need to come up with a strategy for avoiding CSS specificity issues. Not to mention you now have to factor in the decision making towards how you will solve each problem. And like you said before, a lot of this also doesn't become apparent "until you're using it at scale". And yet, you don't acknowledge any of this in your article.

you absolutely don’t need to use Pollen, it isn’t some crazy new framework.

Then perhaps don't write an article title and pitch that sounds like you're created this crazy new framework that solves all of Tailwind's issues?

what I’m trying to get across is that the platform already has a solution to the value tailwind provides, and the style-by-classes abstraction introduces a lot of difficult problems that often don’t become apparent until you’re using it at scale.

Great. But you're not doing a very good job at this by omitting pros and cons from both sides. And no, praising Tailwind at the start of the article isn't quite what I mean. I know you had fair reasons to omit a lot of information and important considerations when choosing Pollen over Tailwind (since you clearly have experience with Tailwind) such as that a lot of things should be "obvious" to people that have used Tailwind. However, not everyone reading this has used Tailwind in the past. And all you end up doing is spreading missinformation for the sake of pitching your new library.

joshuaamaju profile image
Joshua • Edited on

Tailwind fan boy right?

sgarciadev profile image
Sergei Garcia

Nope, just someone who prefers conversations stay neutral and unbiased.

Though calling someone a fan boy just because you disagree with them instead of providing valid counter-arguments could be considered immature and I'd advice against it if I were you.

zafaralam profile image
Zafar Alam

Sorry to say this Sergei, but your whole comment is biased towards tailwind.

I think the author is merely providing his opinion on a technology and proving an alternative approch to people new/existing to the CSS landscape and are looking for solutions.

If you disagree with the author's opinion then don't worry about it and keep doing what works for you and that is okay!

joshuaamaju profile image
Joshua

You literally went crazy about someone criticising tailwind. It's difficult to reason with people at that point, so fan boy would do.

sgarciadev profile image
Sergei Garcia

So if the author conveniently omitted important key information from the comparison it's called "providing her opinion". But when I include the details she omitted, it's called "biased"? Something tells me people now throw around the term "biased" too lightly nowadays just to describe any time they dislike it's content.

I think the author is merely providing his opinion on a technology and proving an alternative approch to people new/existing to the CSS landscape and are looking for solutions.

The author provided his opinion in a biased way by omitting key information when it suited their pitch for a new library, I'm not sure how anyone here is missing it. And by omitting information, it does nothing but spread missinformation to people new/existing in the CSS landscape about Tailwind and it's alternatives.

I'm aware Tailwind is not a silver bullet either and it absolutely has it's downsides. However, for the comparison to be fair, it needs to include all valid pros and cons from both sides, not just the ones that suit the author writing it.

Collapse
nickfotopoulos profile image
Nick Fotopoulos

Madi only stated what everyone who uses Tailwind already knew. Also, the comparison was necessary as Pollen was "inspired by Tailwind".

Collapse
justindmyers profile image
Justin Myers

It's LITERALLY the concept of Design Token.

Pollen has absolutely nothing to do with Tailwind. She's using Tailwind to get attention to her framework, nothing more.

Collapse
devwillis profile image
David Willis

Nothing can ever be improved if it's not okay to think critically.

Collapse
hellojere profile image
Jere Salonen

If you don't like X article, don't read it. But you don't need to look down on it. If you've learned a library with a paradigm, why not focusing more on writing about the positive sides of it?

^such a narrow-minded approach to anything in life.

Collapse
joshuaamaju profile image
Joshua

The metaphorical snake eating its own tail

Collapse
andersbjorkland profile image
Anders Björkland

How can you write something so compelling when I've put so much effort to get semi-comfortable with Tailwind?! 😉

It's often so long between the projects where I use Tailwind that I'm constantly on their docs (they are great by the way). But it's adding an extra step for me. I know how to do something in CSS but I'm using the docs to find what the utility class is for what I want to do. I've been most happy styling when I've used SASS modules. But it's no denying that regular CSS variables are greatly appreciated!

Thanks for the write-up! I'm gonna stare into the mirror for a bit and see if I'll just yeet a dependency where regular CSS makes more sense 🤔

Collapse
natescode profile image
Nate

Ignore the post. Stick to tailwind if you’ve been learning it.

Collapse
andersbjorkland profile image
Anders Björkland

No, I think the post raised some valid points. Sure, it's good knowing such a popular tool as Tailwind because I encounter it in other projects. But for myself, it doesn't really speed up my development and SASS modules are a good way to manage my styles, making it easy to maintain over time.

Still, I like what Tailwind has done for me. I started using it at a time when I had terrible style structure. It was a horrible jungle in style.css. Tailwind was a gust of fresh air and made my styles a bit more maintainable in comparison.

natescode profile image
Nate

It really didn’t. It was just a post to crap on Tailwind to sell the OPs Pollen framework.

Utility based CSS is valuable to understand and if you haven’t grokked it yet then continue. Sass based components still have issues with cascading and naming etc.

Just because Utility CSS (like Tailwind) has limitations doesn’t mean it isn’t valuable or “bad” and needs to be replaced with yet another framework that the OP is trying to sell.

joshuaamaju profile image
Joshua

Like, you don't have to try that hard. You love tailwind, that's fine.

natescode profile image
Nate

No trying. Just don’t like posts trying to sell their framework. I use Sass and bootstrap grid at work just fine.

Collapse
terworth profile image
Pascal • Edited on

Yo! Stop shitting all over the comment section folks. As some of you said, if you don't like it, don't use it. Stop taking place for a framework as if it was a person. IT'S A TOOL. And as it is with tools, new ones come out, new ones will be similar to old ones and some will be more or less effective. It's all about what you need to do. Just then you should think of how to do it. And in times like these where everything is overly complicated, there's no place to say no to something that's trying to make our life just a little better. If you think this post/framework is valid, great! If not, why even bother?
I myself love tailwind and won't stop doing so, because It does most things better than most if not any other framework I've used before (And I tried most already). I will consider Pollen too though. I love CSS variables since they came out, and if Pollen makes sense in that regard, there could be projects where it would make sense to use it. I love new tools. And you should too. 🤓 And Pollen and Tailwind kinda share the same principles and ideas anyways. Less is more.

Collapse
madeleineostoja profile image
Madi Ostoja Author

Thank you 😌

I really didn’t mean to start a flame war. Tailwind is a solid framework written by some very smart people. I think it introduces some problems, especially at scale, but if it makes sense for someone’s use case then awesome!

Collapse
joelbonetr profile image
JoelBonetR

I completely agree, I would say more: Tailwind never was a solution.
Using Sass modules properly gives you the same source of truth and theming capabilities without messing with the structure on a much more maintainable way.

For me, Tailwind is so absurd that you need to learn the entire CSS API in a wrong way that makes you able to work only with tailwind projects while learning the proper standard API from CSS and the capabilities of Sass leads you to a top tier front end dev.

The refactors when using tailwind due to re-designs are just hilarious and I bet it will die before it reaches the successful status as a tech. That and the bloatware in the structure are the main reasons for which it will probably die sooner than later. Imagine having to edit like 300 html elements changing some classes to another ones just to fit the new design. I'll leave in a blink 😆

For reference, currently there's only 1 job available on LinkedIn that mentions "Tailwind".

Collapse
sgarciadev profile image
Sergei Garcia

Using Sass modules properly gives you the same source of truth and theming capabilities without messing with the structure on a much more maintainable way.

"much more maintainable" is debatable. Since CSS class name organization has been a staple issue for decades, something Tailwind does away with. Your HTML may be less messy, sure, but you are moving the organization problem to your CSS files where it can become an even worse nightmare.

Imagine having to edit like 300 html elements changing some classes to another ones just to fit the new design.

Tailwind doesn't do away with reusable classes, they still allow them in the shape of components. And should you be building a SPA with React, Angular or Vue, you would simply change that component affected. If you need to update "300 elements" for even a small design change, you aren't using Tailwind correctly.

Then again, I don't blame you for thinking this. I had the same reaction as you the first time I learned about Tailwind CSS. And only after seeing it in action in a production project did I finally start to understand its benefits.

Collapse
joelbonetr profile image
JoelBonetR

Along with a SPA library like React or a framework like Angular, Next or Vue I use CSS modules with a good architecture on it.
There's a theme.scss that exports the color-related stuff, a grid.scss that does the obvious and a global.scss that exports utilities and similar stuff. All the color-related stuff is declared inside theme (this allows for a quick reaction to design color changes) and what belongs to each component is inside the component directory as component.module.scss

it's just a matter of good architecture and experience. Of course if the devs are generating dummy classnames constantly it will be a mess but there's a nonsense on comparing the worse use cases as there's no tech to deal with that.

Of course you can shape reusable components in tailwind and tailwind at all can be fine till it's not, and the "till it's not" happen when there's a refactor needed due to a redesign, it increases the chances for something to go wrong with design context (the same component looking different depending on the page it's shown).

My opinion is on the main hand due to an analysis and POC did 2 months ago comparing tools for a changes proof code, long story short: custom implementation using Scss inside Next.

Also the team having experience on that is a keystone but also the tech community and similar projects that applies it. As I've said, 1 job available with the keyword "Tailwind", there's a dark future for it in my opinion; just good for people that hate CSS so they learn it the bad way, the same when you add chicken with the vegetables to a kid so he don't cry 😆

sgarciadev profile image
Sergei Garcia • Edited on

My opinion is on the main hand due to an analysis and POC did 2 months ago comparing tools for a changes proof code, long story short: custom implementation using Scss inside Next.

Bingo. A POC is often not enough to get a good enough idea of something. And like I said before, I don't blame you for feeling this way. It's absolutely a big change in terms of paradigm. And people, by nature, fear change (sometimes irrationally). Many things we take for granted today as "the best practice" took generations to receive widespread adoption. Only time will tell if this is another of those moments.

1 job available with the keyword "Tailwind", there's a dark future for it in my opinion

If anything, this is a terrible way to gauge a product's viability. All major libraries started this way. And if the State of CSS global survey teaches us anything, is that Tailwind is quite new, and yet is having exceedingly high adoption numbers thanks to it's record-high user satisfaction and interest to learn it. I guess we'll find out in the coming weeks once the State of CSS 2021 survey comes out to see how much Tailwind has grown in 2021.

Collapse
andrasna profile image
András Nagy

Excellent post!

I have been trying to write CSS in a similar fashion.

One other advantages of Tailwind often cited is how we don't have to come up with selector names.

However, why give up an opportunity to explain a portion of code by giving it a name?

If we assume we are writing components of reasonable size, which already have unique names, then we have not avoided naming things. And we might as well use those same names for scoping our CSS - by scoping I mean either by a convention like BEM, or using something like CSS modules.

Collapse
justindmyers profile image
Justin Myers

Because naming is literally one of the hardest problems in development? Why do you need a name in the first place?

Also, Tailwind still allows you to use your own names with @apply.

Does no one actually read the Tailwind docs before trying to shit on the framework?

Collapse
madeleineostoja profile image
Madi Ostoja Author

Tailwind isn’t the only way not to name things. I use css-in-js myself and much prefer that way of doing things, but that’s neither here nor there.

And yes I’ve used tailwind extensively and read all their docs. I seem to have really upset you I’m sorry if the article came across the wrong way

Collapse
andrasna profile image
András Nagy

Even if we are using Tailwind, if we are creating components, we can't avoid naming the components. If we already have components, we can have scoped CSS, which makes writing CSS selectors very feasible in my opinion.

Collapse
kozakrisz profile image
Krisztian Kecskes

It is a good article. It is sad some fan boy try to resolve their soul and ego problems here in the comment section. You should write more article and don't worry about these kind of people. Keep it up! Your photos are awesome btw :-)

Collapse
madeleineostoja profile image
Madi Ostoja Author

Thank you so much!

Collapse
jackmellis profile image
Jack

Ah another week another "I don't like tailwind because" article. There are a few valid points but after about 18 months of using tailwind in several projects, I can say I'd find it pretty frustrating to go back to css or css-in-js again. Tailwind just makes styling fast and easy.

If anything, the verbosity of tailwind's class combinations works perfectly with view frameworks (React/Vue/Angular/etc) to abstract your styled elements into semantic components.

Anyway I'm not here to try and convince you to like tailwind. Some people love it, some people hate it. That's fine. Unless you're joining a new team where they use it extensively and you have to just suck it up and get on with, I suppose 😂

Collapse
madeleineostoja profile image
Madi Ostoja Author

That’s totally fair! I won’t deny tailwind helps speed up prototyping etc, and it’s not so much “I don’t like because X”, it’s that after using it in my new team where we do use it extensively, there are a bunch of issues that a lot of people might not realise until they’re at scale. Like it’s not that tailwind is some horrible stupid framework, I spend the first chunk of the article praising its ideas. It just has limitations to be aware of, which I think have better solutions in CSS. But if it works for you then awesome, it’s a solid library.

And for everything that is coming for my throat saying I didn’t present a balanced argument, I mean, the article was already huge, and look at the hype around tailwind presenting it as the panacea for our problems and a new way to style things. Tailwinds own rhetoric certainly doesn’t mention any limitations 🤷🏻‍♀️

Collapse
ortonomy profile image
🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝

YES! This guy gets it

Collapse
hectorromo profile image
Hector Romo • Edited on

For all who thinks this is a way to sell in Pollen, read the article:

Full disclosure: I wrote Pollen. But I'm not trying to sell you on adopting it. I'm trying to sell you on the ideas behind it for your own work.

Good points and valid arguments in my point of view.

Collapse
estebanrocha profile image
Esteban Rocha • Edited on

Software engineering is full of narrow-minded people who can't stand a critique.

Thanks to the people that dare to critique the status quo is why we can advance, I personally always felt like Tailwind will become the next Bootstrap, it's popularity is incredible as allows people who don't know CSS to ship.

Nevertheless I have use it and I understand it works in some scenarios, but I also prefer to use a similar approach by using the incredible tooling, APIs and new specs that CSS has, thanks for the article @madeleineostoja

Collapse
royz profile image
Rajorshi Roy • Edited on

I just created an account here just to tell you how much I love this article. I agree with almost everything you said and I had most of these thoughts ever since I first tried tailwind. It blows my mind how every youtuber praises tailwind without mentioning the downsides.

Edit: I have nothing against tailwind. I just believe you should be aware of both good and bad sides of a framework/library/tool before you dive into a large project.

Collapse
madeleineostoja profile image
Madi Ostoja Author

I’m so glad you found it helpful!

Collapse
brittonwalker profile image
Britton Walker • Edited on

Not being into Tailwind is totally valid. Using CSS variables is totally valid. I like to use Tailwind using @apply while creating BEM classes. I find it extremely useful, fast and easy to read doing something like:

.card {
  @apply py-1 lg:py-2 lg:flex lg:justify-between lg:items-center;
  &__title {
    @apply text-gray text-sm lg:text-lg;
  }
}
Enter fullscreen mode Exit fullscreen mode

It's become more of a property generator for me if that makes sense. It's really the variants and extendability that shine along with the new JIT.

Collapse
joshuaamaju profile image
Joshua

At that point why not just write css. I can probably consider the media queries part. But py-1, come on.

Collapse
brittonwalker profile image
Britton Walker

I don't solely use Tailwind to write py-1 but I think we can all agree py-1 is still faster to write than padding: 1rem Xrem... cOmE oN

regislutter profile image
Régis LUTTER

Actually, it's more like
padding-top: 0.25rem;
padding-bottom: 0.25rem;

So I totally agree, I prefer py-1.

brittonwalker profile image
Britton Walker

@regislutter Exactly, your example is more accurate. I also want to point out in the newest version you could do this py-[30px] etc. which is very handy.

You can also take what you need and leave what you don't. For example, I probably wouldn't ever write this if the design called for it pt-1 pr-2 pb-3 pl-4 md:pt-2 ... lg:pt-3 ... xl:pt-4 .... just out of preference, especially if you have a lot of other styles going on in it. However, there are a variety different ways to handle you could handle that. You could just write your normal css padding shorthand and write them in respective media queries as necessary.

You could use multiple @apply statements organized by query (or whatever you want, variant, spacing, etc).

.card {
  @apply py-2 px-4;
  @apply lg:py-3 lg:px-5;
  ...
}
Enter fullscreen mode Exit fullscreen mode

Or you could put them in the @screen directive:

.card {
  @screen lg {
    @apply py-3 px-5;
  }
}
Enter fullscreen mode Exit fullscreen mode

A lot of the common css frameworks/tools provide utility classes. I made pretty heavy use of Bootstrap's utility classes way before Tailwind was born. The examples I provided are just one of many things I like and use on a daily basis. It becomes a situation where you or your team would need to agree on the approach based on what works for you and define your house style. At the end of the day all of this could obviously be written by hand without tools and frameworks. These tools are meant to help improve your workflow and should be evaluated for your needs.

Collapse
regislutter profile image
Régis LUTTER

I don't see why py-1 is worth than the idea of the post, which is :
--small-padding: 0.25rem;
padding-top: --small-padding;
padding-bottom: --small-padding;

Collapse
seangwright profile image
Sean G. Wright

I'm sad to see a lot of these comments. People seem so angry and offended. 😒

Collapse
madeleineostoja profile image
Madi Ostoja Author

Yeah tbh this is gonna be my first and last article on Dev.to

Like I know this is a hot topic, and I mention another library (which I also say you prob don’t need, it’s literally a collection of variables), but damn. They be coming for my throat lol.

Collapse
miketalbot profile image
Mike Talbot • Edited on

I too hope you write more articles. Promoting debate is good, the response you've got does contain some comments that show a surprising level of vitriol to something that you've clearly thought about deeply and inspired something you've given to the community for free. We don't have to agree with your conclusions to thank you for your work and your effort in creating this piece.

Collapse
juli91 profile image
Juli (she/her)

I'm so sorry for all the hate comments you get. I, for one, enjoyed your article as it was neither one of these "Tailwind is the best damn thing" articles nor a "Tailwind is total crap" article.

And as for what Tailwind can and cannot do: Everyone should just make up their own mind instead of coming for other peoples opinions.

I hope you'll write more articles!

Collapse
seangwright profile image
Sean G. Wright

I thought your post was very well written. I hope you continue writing here!

These angry developers feel like they have the one true answer, that their experiences and conclusions must make sense for everyone else. They act like they have ownership over the technology they use because they made the choice to use it, and that these choices represent them as people.

It's immature, disappointing, and in some cases results in cruel and compassionless responses.

You don't deserve this, at all.

These people need to step back and self reflect some.

Collapse
jakarlse88 profile image
Jon Karlsen

I haven't used Tailwind, but enjoyed this article nonetheless. I'll keep its arguments in mind, and if I ever consider using Tailwind I'll evaluate said arguments based on their merits and drawbacks in relation to my specific use-case—as one part of several in a broader evaluation.

I also appreciate that the author based on an analysis of a perceived problem came up with an example solution (which is pretty much our collective job description). I think that's a commendable mindset, no matter what you think of the solution specifically. It's a shame that what could have been a quite fruitful mutual discussion has degraded to schoolyard antics, here in the comments.

Collapse
andrasna profile image
András Nagy • Edited on

Let me ask a question here.

We generally agree we probably shouldn't write inline CSS.

But I have been thinking about a process like this:

Write inline CSS when it would be inconvenient to introduce a new selector. For example for "layouts" or "wrappers" that are likely flex or grid containers with some margin or padding.

Having stuff like this can get hideous I think:

  .wrapper {}
  .wrapper-services {}
  .wrapper-sidebar {}
  /* And so on...*/
Enter fullscreen mode Exit fullscreen mode

The problem is, many-many different kind of things need flex/grid containers to function as "wrappers".

Of course, we could have something like this instead, which is better I think:

  .services {}
  .sidebar {}
  /* And so on...*/
Enter fullscreen mode Exit fullscreen mode

But the problem I see here, is that now we have all these larger "blocks", that are again probably just grid/flex containers that are nothing more than wrappers.

Tailwind solves this problem quite well I think.

But I think this is a case where it may be better to just inline the styles at first.

Then, if we see a repeating pattern of inline styles, we may extract those styles into a selector, if we think this improves the code.

As long as we have consistency through custom properties, I am not sure why we wouldn't do this.

Even if we try to achieve not having inline CSS, I believe it may be a good idea to let writing inline CSS at least be part of the development process. And maybe for some styles, inline CSS is optimal - like layout specific rules.

What do you think?

Collapse
madeleineostoja profile image
Madi Ostoja Author

The problem with inline CSS is you lose access to every pseudo element, pseudo selector, state, and media queries.

Personally I use CSS-in-JS so the class naming thing isn’t an issue, but even if you were writing regular CSS it seems like a pretty minor problem compared to the sort of things Tailwind introduces

Collapse
andrasna profile image
András Nagy • Edited on

That is true. However, we can still use clamp() to achieve responsive resizing for things like spacing and fonts.

Or we can write stuff like:

:root {
  --background-foo: blue;
}

@media (min-width: 600px) {
  :root {
    --background-foo: green;
  }
}
Enter fullscreen mode Exit fullscreen mode
<div style="background-color: var(--background-foo)"></div>
Enter fullscreen mode Exit fullscreen mode
Collapse
justindmyers profile image
Justin Myers • Edited on
Collapse
helmsb profile image
Blake Helms

There are some valid criticisms on Tailwind but for me at least it misses the true beauty of Tailwind, hyper-productivity.

I have been building web applications using CSS for over 20 years and I have used everything from hand-written bespoke CSS to every framework under the sun but Tailwind was an absolute game-changer for me. I immediatly had a huge gain in my productivity as making the classes utilities allowed me to quickly apply them without leaving the markup. I didn't have to jump from HTML to CSS then back again. Add a class and it just worked.

The classes are also predictable so when I learned the pattern I had an intuitve sense of what was possible. As I found gaps or areas that I wanted to customize I could easily extend them with my own classes.

This hyper-productivity also had the benefit of giving me more "courage" to expirement. I am much more comfortable trying things becuase I can apply a few classes and start getting a feel for how different styles might look.

Tailwind allows me to quickly build great looking applications with a fraction of the effort I've used with other tools and I did not need to learn any technologies that I wasn't already using.

Collapse
madeleineostoja profile image
Madi Ostoja Author

Yeah that’s a totally valid use-case for tailwind, and if I was building a quick prototype that didn’t need to scale I’d probably use it myself.

I more wanted to point out some issues that I have come across at scale with it, because it’s often presented as a flawless new way to do things, which isn’t the case

Collapse
helmsb profile image
Blake Helms

I guess I disagree with the premise that Tailwind only makes sense for prototypes and can’t scale. I’ve built/maintain a number of projects with some using Tailwind and others using various SASS/CSS frameworks and the Tailwind projects are an order of magnitude easier to maintain.

That is what attracted me to Tailwind. I find it easy to build projects AND easy to maintain.

I’m not saying it’s going to work for everyone but it’s certainly NOT only for PoCs.

Collapse
anubra266 profile image
Abraham Anuoluwapo

@madeleineostoja I beg you, let this not be your last article, hate comments just mean you had something really worth sharing. You wrote this perfectly well, this is basically the model for a good research work. Bringing light to both advantages and disadvantages, your findings, then you ended it with your solution. Come on, that's how it's to be done. The people who really deserve to criticize the shortcomings of something, are those that are able to produce a better way of going about it, and that's exaclty what you did.

Thanks for the great write up, and please keep it up.

Collapse
rangercoder99 profile image
RangerCoder99 • Edited on

I wonder why not just use something like "@apply font-bold py-2 px-4 rounded;" in your css file? It would be a lot less typing than Pollen. Class soup problem sold... if you want shorter lines just use another @apply line! The huge thing about Tailwind, is speed... test out multiple css styles with just hitting a few keys thanks to auto complete.

Collapse
madeleineostoja profile image
Madi Ostoja Author • Edited on

Because for all the benefit of saving a couple of keystrokes you're introducing a whole new DSL and preprocessor requirement, and by using @apply you're also ditching of the benefit of atomic stylesheets that Tailwind gives you, since it literally just copies and pastes those style rules into your CSS

Collapse
andrewnatoli profile image
Andrew Natoli

Stuffing CSS variables into a tailwind config file seems to be a popular route, so cheers for implementing the principles of Tailwind with a CSS-first approach; not requiring config files and build tools to get there.

Before I clicked into Pollen’s docs I was looking for your take on Tailwind’s @apply but realize now you don’t need to mention that since your point is about configuring utility classes through JavaScript vs configuring them through CSS.

Great to have the alternative way to do things 👍

Collapse
kreha1 profile image
Tomasz Rymkiewicz

Um, as other people haven't pointed out, you can use @apply to move your inline-styles-like classes into a custom class. What's more, the whole deal with tailwind is that you can customize your config file.

@apply works great with frameworks that implement scoped css block (Vue, Svelte). There is also windicss which expands tailwinds feature set, giving you pseudo-selectors, the ability to combine variants and lately the atrributify mode - using (most of the time) the first bit of tailwind css class as a HTML attribute to group classes.

Collapse
madeleineostoja profile image
Madi Ostoja Author • Edited on

I touched on it in another reply, but if you’re using @apply what benefit are you getting over regular CSS with a strong design system other than a few saved keystrokes? The price you pay — introducing a whole new DSL and preprocessor — seem steep to me for that. Like, you shouldn’t need a config file to write CSS. If you use the CSS variables we already have then you can “customise” your design system in a single css file, and do it dynamically with JS in the browser too if you want.

I haven’t heard of windicss, and it sounds cool. But again a lot of the things you mentioned are plugging feature gaps that shouldn’t exist in the first place. All of these issues go away if we just abandon the style-by-classes paradigm

Collapse
justindmyers profile image
Justin Myers

"Like, you shouldn’t need a config file to write CSS. "

Weird, because you don't need a config file to use Tailwind. It works just fine along-side normal CSS.

Again, seems like you don't even understand what Tailwind is, you just want to advertise your "library".

joshuaamaju profile image
Joshua

Guy, take it easy. You're a tailwind fan boy. God...

Collapse
hnicolas profile image
Nicolas Hervé

Your "library" is nothing more than a couple of CSS variables, I don't see how learning the variable names introduced by pollen is different from learning tailwindcss "DSL" that is just a bunch of class names.

Collapse
madeleineostoja profile image
Madi Ostoja Author

This is literally the point. You can get the core benefits of tailwind with just “a couple of CSS variables”. Using them, or your own, in any way you can use CSS, means you don’t have to reinvent CSS with the style-by-classes paradigm

Collapse
einlinuus profile image
EinLinuus

I guess you have never worked with TailwindCSS. It's so much more that just variables.

  • A few elements next to each other and you need a line between them? divide-x / divide-y
  • Need spacing between elements? space-x / space-y
  • You need a grid? grid grid-cols-1 md:grid-cols-2 and you have a responsive 2 column grid layout
  • Want to change the color of an element when you hover over the parent? Add group to the parent and group-hover:text-red-500 to the child - done

In my eyes, TailwindCSS is even easier than writing regular CSS. Example: Grid. 2 Columns in TailwindCSS: grid-cols-2 / Regular CSS: grid-template-columns: 1fr 1fr);

And "saving a few keystrokes" - it saves A LOT of time to just write your html and do styling directly inside the class attribute, thank thinking of a class name, navigating to the css file and do it manually there.

Collapse
justindmyers profile image
Justin Myers

No, the point is that you don't even understand Tailwind.

It's not just "some variables".

Collapse
alpharime profile image
Adejori Eniola

I personally believe your point is actually pointless.. since you can come combine tailwind utility classes into a single class using the @layer component and @apply reducing the long class list in your Html all though I use it mostly with React so jsx.
Promote you work
Don't try to bring down others

Collapse
ctsstc profile image
Cody Swartz

I'm wondering what the problem is with just good ol sass/scss, I'm sure there's some handler too that can convert your sass variables into browser variables or just write your variable as a modern variable.

I agree with another person's comment about how they are often going back to the documentation on these. I've been feeling the same with bootstrap lately, often it has great responsive helpers but then you run across the few things that don't, or it covers like 90% of flexbox cases and then falls short. I know you can modify their helpers but then like you said you bloat the system when you add something like a new size or color which then has to get pushed out to every helper for every permutation, and I doubt many people are thinking about that when all they are doing is wasting their time digging through documentation and stack overflow trying to solve their otherwise trivial problem, but I feel that many people fall into the trap and time sink of trying to be a purist that wants to do it all using their thick shiny tool.

I'll have to check out your lib next tone o get a chance.

Collapse
sgarciadev profile image
Sergei Garcia • Edited on

Of course you can mix Tailwind's more useful classes with regular CSS. But then you're breaking the Tailwind style-by-classes abstraction, and you have to maintain two seperate styling touchpoints for every element.

It seems like author forgot that a large amount of Tailwind's community uses Tailwind for SPAs (React / Angular / Vue) where components can leverage JavaScript logic with Tailwind classes.

Even Tailwind's Docs recommend not needlessly creating classes and prefering writing components when an option.

And while the article has some great points, I can't help but feel this comes off as somewhat of a hot-take of Tailwind for the sake pitching yet another library that solves some problems while introducing old (traditional CSS project file and style organization, dealing with specificity) and a potential for new undiscovered ones.

I'm sure Pollen is a great library in some cases, but I'm not sure this was the right way to introduce it. Since it makes me wonder what pitfalls or issues Pollen might have that he/she is not mentioning just like with Tailwind.

Collapse
madeleineostoja profile image
Madi Ostoja Author • Edited on

Heya, I use CSS-in-JS in React myself, and have used tailwind in production at scale in that context, so not entirely sure where you’re coming from. The point you highlighted wasn’t about creating your own classes, it’s about what Tailwind has had to do itself to maintain its style-by-classes paradigm. By creating classes like .block etc that add no value whatsoever over normal css.

Re: “yet another styling library”, as I mentioned at the end of the post you don’t need to use Pollen, it just takes a lot of the helpful utilities from Tailwind and reimplements them in native, regular CSS. Absolutely nothing about it dictates the need for “traditional” style organisation or worse inheritance problems (again I use it in a css-in-js context). You can literally check out the source, it’s a few blocks of CSS variables.

If anything it’s proof that you don’t need a styling library, especially not one that dictates a whole new paradigm of styling like Tailwind

Collapse
sgarciadev profile image
Sergei Garcia

Heya, I use CSS-in-JS in React myself, and have used tailwind in production at scale in that context, not entirely sure where you’re coming from. The point you highlighted wasn’t about creating your own classes, it’s about what Tailwind has had to do itself to maintain its style-by-classes paradigm. By creating classes like .block etc that add no value whatsoever over normal css.

My bad, when I read in order to apply a consistent set of values with classes, it sounded a lot like you were describing the generic use case behind classes. I interpreted this incorrectly.

By creating classes like .block etc that add no value whatsoever over normal css.

I kind of agree with this. But it's not like the opposite side of the spectrum isn't filled with issues. Writing semantic CSS classnames that carry "value and meaning" is an equally large minefield.

Re: “yet another styling library”, as I mentioned at the end of the post you don’t need to use Pollen, it just takes a lot of the helpful utilities from Tailwind and reimplements them in native, regular CSS. If anything it’s proof that you don’t need a styling library, especially not one that dictates a whole new paradigm of styling like Tailwind

And yet, you pitched it with an article title ("Tailwind isn't the answer") that implies there's an objectively better solution to Tailwind CSS on the horizon (in the shape of Pollen). Don't get me wrong, I agree that there is some great value in Pollen for specific scenarios and uses cases. I'm just not sure pitching it by attacking Tailwind by omitting key pros/cons to make Pollen seem objectively better was the right approach, as it can lead to a lack of confidence.

madeleineostoja profile image
Madi Ostoja Author

Sorry if it came across that way, but the better solution to tailwind on the horizon is, just, using CSS. And CSS variables in particular.

Collapse
nnowwakk profile image
nnowwakk

I'm not saying Tailwind CSS is a magical solution to everything but all of your examples can be done "the Tailwind way" as well.

Each of these tools is a poor facsimile of the functionality gaps it has to fill. Want an :nth-child or ~ sibling selector? Back to CSS.

Tailwind has selectors for :first-child, :last-child, :odd-child and :even-child. Those cover most of the use cases but in case you want a class only on the 7th-child, the easiest way is to just put the class on that element instead of using the pseudo-selector on the parent element. Or if you are using a front-end framework to dynamically add the elements, you can add the logic of adding the class to the 7th child in javascript.

For siblings, usually you'd just add the classes to the element itself but you could also use the peer-* variants if you need to depend on a sibling element's state.

Want to target the devices between two breakpoints? Back to CSS.

I'm not completely sure what you mean with this but if you only want a class to be applied to let's say the md: breakpoint then you can just set the style back to the original on lg:. For example bg-black md:bg-red-500 lg:bg-black is red only if the window is 768 - 1024px wide.

Want to target children of an element? Back to CSS. You get the picture.

The whole idea in Tailwind is to apply the styles for each element itself so ideally you'd add the class to the child element. If that's not possible then you can create a selector for it yourself or use tailwindcss-children -plugin for example.

Collapse
ortonomy profile image
🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝 • Edited on

Tailwind has to reinvent everything regular CSS can already do.

Additionally this completely misses the point of tailwind and why its existence is necessary.

I would MUCH rather write inline styles (if it wasn't for the obvious draw backs and issues with specificity) and keep the markup close to the styles so when I look at the code I can tell exactly what it's meant to look like and behave like on the page.

Classes like 'button' or 'button-container' are literally meaningless and I have to go looking for the CSS definitions to find them. CSS-in-JS and Vue.js get closer to this, but still keep the information in a separate place.

There's no denying that Tailwind is hideous.

And this knee-jerk reaction is monstrous blinkeredness due to the doctrine herp, more words bad.

It's a descriptive list of abstracted rules which are easily maintainable over semantic classes in place.


I have a lot time and use cases for CSS variables, I use them for ALL my in-house projects/design systems as a basis for my own stripped back utility class library.

But if you look at tailwind, it also relies heavily on css vars declared in root as a basis for it's extensions for size, color, etc.

So I'm not really sure what the point of this was. Like apples and oranges?

Collapse
regislutter profile image
Régis LUTTER • Edited on

I don't really see how using CSS variables is better.
From your example :

button {
   all: unset;
   font-family: var(--font-sans);
   font-size: var(--scale-00);
   font-weight: var(--font-medium); 
   line-height: var(--line-none);
   padding: var(--size-3) var(--size-5);
   background: var(--color-blue);
   border-radius: var(--radius-xs);
   color: white;
}
Enter fullscreen mode Exit fullscreen mode

You can do that in Tailwind with @apply like :

button {
  @apply font-sans text-xs font-medium py-3 px-5 bg-blue-100 rounded rounded-xs text-white;
}
Enter fullscreen mode Exit fullscreen mode

There is clearly no advantage to the variables.

Also, Tailwind is really useful to work with designers (and with Figma for example). They use a Tailwind template and you can clearly see the padding they want, you have the color and hue gradient applied, the text size, etc. You just have to type the Tailwind class corresponding.

BEM + Tailwind is for me really versatile. And if I need an extra responsive margin on an element just one time, I can do it in no time (exemple class="button mt-2 md:ml-2 md:mt-0")

[Edit] :
And totally forgot about useful classes like divide-x divide-y space-x space-y dark: ring-

Collapse
tomhermans profile image
tom hermans

80/20 rule. With tailwind I have sensible defaults and sensible named classes which I can use in a modular way. Without having to write yet another css boilerplate.
Leaves a lot of time for the more custom stuff.
And try adding to a large project where an edit to class x can possibly bring complete mayhem to existing templates. Not so with single use utility classes.

Collapse
tomhermans profile image
tom hermans

And I love writing css and using css custom properties. Not having to write display:flex in dozens of components or have all kinds of variants of the same component with minor differences and having to name all of them..

Collapse
justindmyers profile image
Justin Myers • Edited on

Design tokens are not a framework.

You created a "framework" of CSS vars. How is that a framework. It's just a set of variables, nothing more and the entire concept is called Design Tokens and has been around for YEARS.

Tailwind offers so much more than that and the fact that you didn't discuss that at all just shows your bias. And the fact that your wrote Pollen, so you have no interest in showing why it's worse than Tailwind anyways.

Collapse
madeleineostoja profile image
Madi Ostoja Author

Wow okay lot to unpack here. Pollen is absolutely not a framework, that’s the whole point. The point of the article is that you don’t need a framework like Tailwind, and if you don’t want the ‘design tokens’ in pollen, based on tailwinds own tokens, then don’t use it, write your own bunch of variables to bring consistency to CSS in a way that doesn’t require a whole new styling paradigm with its own issues.

This isn’t a framework v framework thing, it’s a critique of some of tailwinds implementation choices, and an example of what can be done without them. I literally end the article saying you probably don’t need either of them 🤷🏻‍♀️

Collapse
wintercounter profile image
Victor Vincent • Edited on

I using YouEye the last few years which comes with the benefit of Tailwind's productivity, but at the end it's just CSS. Tailwind is also a subset of CSS basically, well constructed/collected defaults let's say. I'm using it with shorhands so it basically achieves the same as TW's short classes, but at the end I have the full power of CSS at my fingertips, not just what the library offers. There is no extra DSL, no inheritance/encapsulation/naming problems. States, pseudo elements, Media Queries in an inline fashion.

Collapse
jonosellier profile image
jonosellier • Edited on

Tailwind is excellent if you aren't comfortable with CSS because you're don't have to make it look pretty, everything already is pretty. What tailwind does is boost you to where you need to be for 90% of situations. If you can avoid the other 10% then you are golden.

The issue with tailwind is as soon as you get to that 90% mark, you hit that wall described where you can break the "spirit" of tailwind.

You can avoid this by writing your own classes that (where possible) @apply tailwind utilities for the big stuff that will be used all the time (buttons, form controls, etc.) as well as the tiny stuff (the pseudoselectors, the nth child, etc) that is used almost never. That way you spend most of your time doing what tailwind wants you to do, writing some classes in your HTML.

As with all tools, you can use or abuse it.

Collapse
madeleineostoja profile image
Madi Ostoja Author

Yes totally! Tailwind is excellent for quick prototypes, the problems come up at scale. I just feel for those kind of contexts it introduces more problems than it solves