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