It's important to write about bad frameworks as much as it is to write about good ones, because of two reasons.
First, is the John Stewart Mill argument of "the value of the wrongful idea" - that in making a (good faith) argument for something incorrect, one arrives at a more correct, more complete view by analysis and refutation. Ideas must be continually challenged lest they go stale. Indeed - "one who doesn't understand one's opponent's arguments does not understand one's own" is a maxim I try to apply. When I wrote this article, I tried to look for the good in Tailwind. Why do people like it? (They don't have to write css. They can put style info in their HTML. They can write terser code. It gives them power to do things they don't know how to do in css.) Once I knew why people liked it, I had a much better understanding of why I didn't. (It combines content and presentation. It makes things harder to maintain. The syntax is obscure. You lose the power to do things that you can do in css.)
Second is that someone down the line is going to think: Hmm, should I add Tailwind to my app that has to be maintained by my team? And they're going to google "pros and cons of TailwindCSS". There will be plenty of articles explaining the pros. Here's one explaining the cons. Hopefully I've made a compelling argument not to use Tailwind so that future developers won't have to deal with it.
I agree that it's important to write both good and bad stuff.
Is also important to mention good things tools bring and not only subjective opinion on the bad stuff only. Why not mention both advantages and disadvantages if the aim is to give perspective for those looking to use the tool?
The title and the article itself is written in a negative manner, which is much more like "hey folks, I tried tailwind, I don't understand all the pros, don't understand how it can improve solo/team work, but will pour lots of shit on it'
The problem with "why not mention the advantages?" is that there needs to be advantages worth mentioning.
I mean, I agree with you. There are lots of tools for programmers out there that provide both advantages and drawbacks**.
Before I became a programmer, I actually was a journalist, and one of the things that my co-workers and J-school professors hated was the idea of false equivelance. The typical example is that 99% of scientists would agree climate change is real and manmade, while 1% may disagree, and to give the appearance of showing "both sides", cable news networks would book, on one side, a fringe skeptic, and on the other, a scientist. Or more likely, Bill Nye the Science Guy.
I'm not going to mince words - if I can't find a single positive thing to mention about a tool, I'm not going to go out of my way to scrape the bottom of the barrel to find something.
The thesis of the post is that Tailwind adds nothing. That there are no advantages to be had.
** A good example: Mongoose ODM for MongoDB. I personally wouldn't use it - I think it's too much boilerplate and cruft to add ORM-like structure to the relatively simple syntax provided by the MongoDB native Node drivers, and I don't like the performance hit when I used it (back in 2015). But the advantage is that you can organize how you interact with your DB in a standard way, follow existing models established by decades of relational DB management, and help to acclimate established SQL-heads to Mongo. Mongoose has advantages and disadvantages.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I don't think this is something you can say about articles in general. It's perfectly fine to have an article that says, "I love X because Y" without mentioning its drawbacks - especially on a forum like this, where people will bring up their criticisms in the comments. It's responsible of the author to address those criticisms - or even to say something like, "I don't mind the drawbacks, I expect it to improve in the future" which acknowledges the criticism and moves on.
OP has already said they don't consider the claimed advantages to be legitimate.
Why tag the frameworks "bad" or "good"? Who are we to decide this for others?
If you don't like it - don't use it.
If you like it - use it.
We can take ANY framework and find people who hate it and those who love it.
We are free to express pros and cons of anything, but why not be respectful?
Why trash something if you don't agree with it?
I know many people and companies that love TailwindCSS and appreciate it.
People are putting much effort to produce something that they believe is helpful and will solve problems many of us have. The majority of feedback about TailwindCSS is very positive.
And then other people, based on their OWN PERSONAL preferences, pour dirt on their work.
Why tag the frameworks "bad" or "good"? Who are we to decide this for others?
We are software engineers. And what seperates "software engineers" from software developers is that while the developer can make something, the engineer evaluates, plans, and figures out the best way to make something before making it.
That means we have to take a look at proposed code and proposed tech. We have to take a critical eye to it.
Why trash something if you don't agree with it?
Because this isn't New Orleans Jazz.
I don't like New Orleans Jazz, so I don't have to listen to it. I don't buy New Orleans Jazz albums.
I am not in the habit of making detailed criticisms of what I feel to be the compositional problems of New Orleans Jazz.
But I have never had a team lead, product owner, or stakeholder come up to me and say: "For the next project, I'm thinking that everyone on the team has to learn how to appreciate and play New Orleans Jazz."
Engineers and developers are often required with working with technology that they not only don't like, but which makes their work harder. So when team leaders are thinking about incorporating a new technology into their tech stack, they should look for blog posts like this one to help them evaluate whether or not it's worth a try.
My thesis is not, as you seem to think, "I don't like Tailwind, and therefore YOU shouldn't like Tailwind either". That's a 12 year old's viewpoint of technology criticism.
Rather my thesis is: "If you choose Tailwind for a mission critical application, you will end up making your job harder, your application more brittle, and your team, in the long-term, will suffer."
You may disagree with that thesis, but you need to provide evidence to back your position, and "But I like it, and other people and companies like it, so shut up, you're being mean" is not an adaquate, professional rebuttal.
So will we see an article from you about how shitty New Orleans Jazz is and why no one should listen to them because you said so?
I wanted to answer your comment with examples of articles discussion pros and cons of TailwindCSS,
but decided that you seems to have much more time to write long answers than I do. Plus, having M.A. Journalism must help you with the language... not a lot, as the language you use is not of a high level.
Anyone can google for "tailwindcss pros and cons" and see that there are many results, most of them are pro TailwindCSS, others discuss the cons in polite professional manner, as opposed to your low level mocking language.
My personal experience (I started in 2005, if that's means something, and it does, since you mention your 12 years of experience), is that at my work we had a project to revamp the UI and a guy was hired, we asked him to do it right, CSS-wise he should use SCSS+BEM, and he did.
The product looked good, any changes along the way were fast.
He was the only doing the revamp. Then this guy left and 10 FE developers were left with the CSS. When any of those 10 people needed to look at the CSS that was written and change something, it was a quest. No one understood what was going on and how to find styles, because it was all SCSS functions and mixins. Hundreds of lines of code. Tenths of BEM classes.
We came to a conclusion that we need to throw the new-old CSS as fast as we could.
Then we got introduced to TailwindCSS and tried it on an isolated module. Everyone loved it. We moved faster than ever. We had maybe 50 lines of pretty formatted custom SCSS for that module.
The team loved working with TailwindCSS so much, that when this modules was merged into the main application, a pretty huge one, the rest of the people learned to use and utilize it in a matter of hours and there is no a single person in the team who doesn't want to use TailwindCSS now.
We are progressing really fast and we have very few custom SCSS to maintain and it's easy. Never been easier. And it is extremely maintainable. Plus - prototyping during live sessions with our UI is just a joy.
(That came out longer that I expected).
I can take every point and example you presented from your narrow point of view and make an argument how to change it a little to make it work much nicer than with plain CSS. But many here tried and I don't see the point. If one does not want to see the side of the other - there cannot be a dialog, learning and collaborating.
As many technologies, there are beset practices and design patterns that are emerging, and you didn't mention any of them or mention them in such a way that they looked bad.
So, again, if you think that technology A is not for you and you are sure (no idea who put you into a position to decide for anyone) that it's bad - present the cons, but do it at a level that people will pay attention and not is an unprofessional way you did here.
(I used "professional" and "unprofessional" a lot, because you seem to enjoy using it to describe yourself)
So will we see an article from you about how shitty New Orleans Jazz is and why no one should listen to them because you said so?
You didn't get the point at all, did you?
Plus, having M.A. Journalism must help you with the language... not a lot, as the language you use is not of a high level.
On the contrary, the fact that the language I use "isn't high level" is a massive compliment. :)
I came into J-school from a B.A. in History, and a 720 on the GRE's verbal section. I knew, and used, a lot of sophisticated, convoluted words. My vocabulary was labyrinthine and circuitous when I really wanted to show eggheaded impertinance.
My first J-school assignment came back with a lot of red ink on it. "Use the smaller words," it said. "Write for a smart 13 year old - someone with an 8th grade level of education."
The reason why is because the job of a journalist is to communicate ideas and information, not to obscure them behind flowery language.
Now I'm not going to say that I'm a professional journalist today, but one of the things I can still do well is communicate. If you work in tech, the ability to communicate complex ideas to your team simply is possibly the most important skill you need to know. And to do that, I try to use small words instead of big ones.
There are a lot of really good programmers who might not have a collegiate reading level in English (second-language, self-taught, still young), and I want to communicate to them, too.
So - I know you didn't mean it as a compliment, but thank you.
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.
Now we get a post of tailwind every week.
To summarise quickly - you don't like it, don't use. No need to shout out that it's so bad, no one should ever use it.
It's important to write about bad frameworks as much as it is to write about good ones, because of two reasons.
First, is the John Stewart Mill argument of "the value of the wrongful idea" - that in making a (good faith) argument for something incorrect, one arrives at a more correct, more complete view by analysis and refutation. Ideas must be continually challenged lest they go stale. Indeed - "one who doesn't understand one's opponent's arguments does not understand one's own" is a maxim I try to apply. When I wrote this article, I tried to look for the good in Tailwind. Why do people like it? (They don't have to write css. They can put style info in their HTML. They can write terser code. It gives them power to do things they don't know how to do in css.) Once I knew why people liked it, I had a much better understanding of why I didn't. (It combines content and presentation. It makes things harder to maintain. The syntax is obscure. You lose the power to do things that you can do in css.)
Second is that someone down the line is going to think: Hmm, should I add Tailwind to my app that has to be maintained by my team? And they're going to google "pros and cons of TailwindCSS". There will be plenty of articles explaining the pros. Here's one explaining the cons. Hopefully I've made a compelling argument not to use Tailwind so that future developers won't have to deal with it.
I agree that it's important to write both good and bad stuff.
Is also important to mention good things tools bring and not only subjective opinion on the bad stuff only. Why not mention both advantages and disadvantages if the aim is to give perspective for those looking to use the tool?
The title and the article itself is written in a negative manner, which is much more like "hey folks, I tried tailwind, I don't understand all the pros, don't understand how it can improve solo/team work, but will pour lots of shit on it'
Sad.
The problem with "why not mention the advantages?" is that there needs to be advantages worth mentioning.
I mean, I agree with you. There are lots of tools for programmers out there that provide both advantages and drawbacks
**.Before I became a programmer, I actually was a journalist, and one of the things that my co-workers and J-school professors hated was the idea of false equivelance. The typical example is that 99% of scientists would agree climate change is real and manmade, while 1% may disagree, and to give the appearance of showing "both sides", cable news networks would book, on one side, a fringe skeptic, and on the other, a scientist. Or more likely, Bill Nye the Science Guy.
I'm not going to mince words - if I can't find a single positive thing to mention about a tool, I'm not going to go out of my way to scrape the bottom of the barrel to find something.
The thesis of the post is that Tailwind adds nothing. That there are no advantages to be had.
**A good example: Mongoose ODM for MongoDB. I personally wouldn't use it - I think it's too much boilerplate and cruft to add ORM-like structure to the relatively simple syntax provided by the MongoDB native Node drivers, and I don't like the performance hit when I used it (back in 2015). But the advantage is that you can organize how you interact with your DB in a standard way, follow existing models established by decades of relational DB management, and help to acclimate established SQL-heads to Mongo. Mongoose has advantages and disadvantages.Yes there is almost always both advantages and disadvantages. And it is on every individual developer / team to decide what works best for them.
And it is on the author to cover both sides to provide reader with constructs which will help to choose or reject the tool.
In this case, there are no advantages I could find, only disadvantages.
I suppoes the fact that I could find no advantages but plenty of disadvantages should people decide whether or not to use the tool.
I don't think this is something you can say about articles in general. It's perfectly fine to have an article that says, "I love X because Y" without mentioning its drawbacks - especially on a forum like this, where people will bring up their criticisms in the comments. It's responsible of the author to address those criticisms - or even to say something like, "I don't mind the drawbacks, I expect it to improve in the future" which acknowledges the criticism and moves on.
OP has already said they don't consider the claimed advantages to be legitimate.
Why tag the frameworks "bad" or "good"? Who are we to decide this for others?
If you don't like it - don't use it.
If you like it - use it.
We can take ANY framework and find people who hate it and those who love it.
We are free to express pros and cons of anything, but why not be respectful?
Why trash something if you don't agree with it?
I know many people and companies that love TailwindCSS and appreciate it.
People are putting much effort to produce something that they believe is helpful and will solve problems many of us have. The majority of feedback about TailwindCSS is very positive.
And then other people, based on their OWN PERSONAL preferences, pour dirt on their work.
That's just disrespectful.
We are software engineers. And what seperates "software engineers" from software developers is that while the developer can make something, the engineer evaluates, plans, and figures out the best way to make something before making it.
That means we have to take a look at proposed code and proposed tech. We have to take a critical eye to it.
Because this isn't New Orleans Jazz.
I don't like New Orleans Jazz, so I don't have to listen to it. I don't buy New Orleans Jazz albums.
I am not in the habit of making detailed criticisms of what I feel to be the compositional problems of New Orleans Jazz.
But I have never had a team lead, product owner, or stakeholder come up to me and say: "For the next project, I'm thinking that everyone on the team has to learn how to appreciate and play New Orleans Jazz."
Engineers and developers are often required with working with technology that they not only don't like, but which makes their work harder. So when team leaders are thinking about incorporating a new technology into their tech stack, they should look for blog posts like this one to help them evaluate whether or not it's worth a try.
My thesis is not, as you seem to think, "I don't like Tailwind, and therefore YOU shouldn't like Tailwind either". That's a 12 year old's viewpoint of technology criticism.
Rather my thesis is: "If you choose Tailwind for a mission critical application, you will end up making your job harder, your application more brittle, and your team, in the long-term, will suffer."
You may disagree with that thesis, but you need to provide evidence to back your position, and "But I like it, and other people and companies like it, so shut up, you're being mean" is not an adaquate, professional rebuttal.
So will we see an article from you about how shitty New Orleans Jazz is and why no one should listen to them because you said so?
I wanted to answer your comment with examples of articles discussion pros and cons of TailwindCSS,
but decided that you seems to have much more time to write long answers than I do. Plus, having M.A. Journalism must help you with the language... not a lot, as the language you use is not of a high level.
Anyone can google for "tailwindcss pros and cons" and see that there are many results, most of them are pro TailwindCSS, others discuss the cons in polite professional manner, as opposed to your low level mocking language.
My personal experience (I started in 2005, if that's means something, and it does, since you mention your 12 years of experience), is that at my work we had a project to revamp the UI and a guy was hired, we asked him to do it right, CSS-wise he should use SCSS+BEM, and he did.
The product looked good, any changes along the way were fast.
He was the only doing the revamp. Then this guy left and 10 FE developers were left with the CSS. When any of those 10 people needed to look at the CSS that was written and change something, it was a quest. No one understood what was going on and how to find styles, because it was all SCSS functions and mixins. Hundreds of lines of code. Tenths of BEM classes.
We came to a conclusion that we need to throw the new-old CSS as fast as we could.
Then we got introduced to TailwindCSS and tried it on an isolated module. Everyone loved it. We moved faster than ever. We had maybe 50 lines of pretty formatted custom SCSS for that module.
The team loved working with TailwindCSS so much, that when this modules was merged into the main application, a pretty huge one, the rest of the people learned to use and utilize it in a matter of hours and there is no a single person in the team who doesn't want to use TailwindCSS now.
We are progressing really fast and we have very few custom SCSS to maintain and it's easy. Never been easier. And it is extremely maintainable. Plus - prototyping during live sessions with our UI is just a joy.
(That came out longer that I expected).
I can take every point and example you presented from your narrow point of view and make an argument how to change it a little to make it work much nicer than with plain CSS. But many here tried and I don't see the point. If one does not want to see the side of the other - there cannot be a dialog, learning and collaborating.
As many technologies, there are beset practices and design patterns that are emerging, and you didn't mention any of them or mention them in such a way that they looked bad.
So, again, if you think that technology A is not for you and you are sure (no idea who put you into a position to decide for anyone) that it's bad - present the cons, but do it at a level that people will pay attention and not is an unprofessional way you did here.
(I used "professional" and "unprofessional" a lot, because you seem to enjoy using it to describe yourself)
You didn't get the point at all, did you?
On the contrary, the fact that the language I use "isn't high level" is a massive compliment. :)
I came into J-school from a B.A. in History, and a 720 on the GRE's verbal section. I knew, and used, a lot of sophisticated, convoluted words. My vocabulary was labyrinthine and circuitous when I really wanted to show eggheaded impertinance.
My first J-school assignment came back with a lot of red ink on it. "Use the smaller words," it said. "Write for a smart 13 year old - someone with an 8th grade level of education."
The reason why is because the job of a journalist is to communicate ideas and information, not to obscure them behind flowery language.
Now I'm not going to say that I'm a professional journalist today, but one of the things I can still do well is communicate. If you work in tech, the ability to communicate complex ideas to your team simply is possibly the most important skill you need to know. And to do that, I try to use small words instead of big ones.
There are a lot of really good programmers who might not have a collegiate reading level in English (second-language, self-taught, still young), and I want to communicate to them, too.
So - I know you didn't mean it as a compliment, but thank you.