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>
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>
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);
}
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;
}
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`);
}
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
peppercornstudio
/
pollen
Utility-first CSS for the future
Pollen
Utility-first CSS for the future
Introduction
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;
}
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.
Oldest comments (110)
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 🤔
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
That's patently untrue:
tailwindcss.com/docs/configuring-v...
tailwindcss.com/docs/just-in-time-...
tailwindcss.com/docs/just-in-time-...
It's almost like you've never used Tailwind.
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.
Because for all the benefit of saving a couple of keystrokes you're introducing a whole new DSL and preprocessor requirement, and by using
@applyyou'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 CSSOnce 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?
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
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!
Madi only stated what everyone who uses Tailwind already knew. Also, the comparison was necessary as Pollen was "inspired by Tailwind".
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.
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.
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.
You can't expect people to not elaborate on the important details you omitted.
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.
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?
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.
Tailwind fan boy right?
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.
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!
You literally went crazy about someone criticising tailwind. It's difficult to reason with people at that point, so fan boy would do.
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.
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.
Nothing can ever be improved if it's not okay to think critically.
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.
The metaphorical snake eating its own tail
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.
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.
Well to be honest i disagree with that. But I guess in the end user's experience matters.
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".
"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.
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.
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 😆
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.
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.
" The Tailwind alternative that doesn't reinvent CSS " , that sounds offensive, somehow i feel you wrote this article out of hate against tailwind :)
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.
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
"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".
Guy, take it easy. You're a tailwind fan boy. God...
Nice. I've been planning to do this with SCSS variables which hold CSS variables, that way less to type, but still easier to do theming, switch from light to dark, or comfortable to compact, etc.
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.
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
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.
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.
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.
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.
Its better to use Twin Macro!
Tailwind is the was to go. If you haven't used I suggest you try it out. Way better than writing your own css. With the JIT, Dark mode and autoprefixer you won't need to stress about compatibility
Some comments may only be visible to logged-in visitors. Sign in to view all comments.