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?
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.
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.
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!
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.
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.
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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?
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.
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
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.
Nothing can ever be improved if it's not okay to think critically.
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!