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