Disclaimer: I don't want to engage in the drama. I just think it's important to share experiences to help people make a choice.
Prelude
...
For further actions, you may consider blocking this person and/or reporting abuse
I don't particularly have a problem with Tailwind provided you don't do this. You don't have to, since it compiles down to regular CSS like every other tools does. If you write simple semantic markup and
applyutility classes in the CSS part, you don't need to bloat your HTML.The problem is, that's not an improvement on how people do CSS in the first place, and it's also not how people use Tailwind in the real world.
I do agree
@applygets rid of the benefits, and this is why you should avoid using it. It is openly discouraged to be used by the author. However, it comes quite in handy when you need to style something globally.I actually use
@applyunder two situations when I don't want people to easily copy of my design from just looking at HTML and second when I have conditions like the one Adam showed related to lists of similar element. I would probably make a new component and then apply scoped css using selectors on it with@applythis prevents the bloated HTML. I am doubtful though whether HTML vs@applywhich one will bloat my css.IMHO thanks to Tailwind someone who doesn't know CSS can learn it much faster thanks to great documentation. I am also using this lib for about 3 years now and I recommend it to everyone.
I'll reiterate a general theme from some of the other commenters. The issue is not the tailwinds, the issue is people are not learning how to write CSS by hand. All of these frameworks are great, until you have to do something custom or you have to work out UI bugs that are caused by said frameworks.
At the end of the day this really just comes down to preference. I write CSS by hand and enjoy doing it. I also pull from my own component cache because I have full confidence in that code. I know others that will not deviate from some of these frameworks because they hate writing CSS and don't have the aptitude for it. The important thing, especially when you're working with the team or knowing you're going to hand this project off to somebody else, is to make it digestible by another developer who has no clue about the tools that you're using.
Thanks for sharing your thoughts Brendan. I'd like to comment on some things.
I don't think this is the case. Since Tailwind is just an abstraction over CSS, you still need to understand the fundamentals at some point. Need to apply global styles? You learn about selectors. Need to support more than light / dark mode? You learn custom properties. The path of learning may look different but at the end of the day, it matters that you start learning in the first place.
Besides that, Tailwind also teaches you properties that most other developers don't even know. Examples for that would be blend_mode and font_variant_numeric.
Tailwind is laid out entirely for customization, so I don't know which part you cannot customize with it. Regarding UI bugs, I think it reduces them because you can directly read the styling from the HTML in PRs. If you set up PostCSS you get tools for prefixing which help you avoid browser-specific bugs. Framework specific bugs? I yet have to encounter them. Remember it's just an abstraction of CSS, so chances are you found a new
IESafari bug.When it comes to styling there are always different tools that come with a certain learning curve. All that matters in my opinion is that it is done consistently. I'm glad you have found a solution that you feel comfortable with.
I mean, use whatever suits you best, right?
I like your article. You're writing very differentiated and there's nothing wrong with your arguments.
What's bothering me is that frontend developers feel the urge to take a side for or against tailwind like it's some sort of religion. It's not! It's just a tool :)
I can see how tailwind can be a great utility for any style of app or website. It just depends on your team. If you decide to use it chances are, you might know its benefits and (probable) drawbacks.
If you don't like tailwind, don't use it. That's okay, too.
For myself, I'm not a great fan of it. I just enjoy a clean and DRY codebase with semantic class names (BEM or whatever). But, I have also used tailwind quite a bit to rapidly prototype UIs and really enjoyed the process. Eventually, I still might "convert" back to "traditional" class names but that's my personal decision.
My point is, just because people are taking a stand for or against something (especially if it's "just" about some nerdy developer tools) it's still possible to use the best from both worlds. If you can work with it, that's great! Whatever makes your day easier!
As for the argument that you won't learn vanilla css "the right way" if you use tailwind I just remember back to the good ol' jQuery days! Back then, jQuery was the evil js framework. If you used it as a beginner it would be harder to Lear "real" Javascript, they said. Well, what should I say, I used it heavily as a beginner and I don't feel like I didn't learn the Javascript basics. It was just a great entry into web dev back then even if I wouldn't dare to use it in a project today :)
There is no such thing as a "best" tool for something as that would be a highly subjective standpoint. Maybe, for you, it is the best around there. For others, there might be other alternatives.
Long story short: thank you for a great article about why you chose to use tailwind. This might help others to decide which tools to use.
Thanks, I really appreciate your feedback.
i'm using Tailwind in two side projects and i can say that... since i learned CSS more than 8 years ago... it is like a shortcut to write CSS without having to create a .css file and plus, make your html looks like a mess, and you can get lost on it quickly. i'm wrong? then try use it without componentization. make a plain page with it. make a whole website with it. like those templates from themeforest. it will become a hell. my suggestion is: stick with the roots. plain CSS and BEM as convention.
1) Tailwind requires you to create a CSS file
2) Humans can only parse information to a certain treshold. I think non-component based approaches make scaling messy, and if it stays a simple page the additional classnames are tolerable for me. Templates can be a hit or miss. If they are extensively commented like the ones you get from TailwindUI, it feels okay to me.
3) Use what works for you. I don't think it is a bad idea to avoid abstractions, but conventions are often disregarded if not enforced. Tailwind just scaled well with teams for me.
thanks to the article. it really helped
How is PostCSS dead? There’s regular releases on GitHub.