Tailwind is the new kid on the block; it's fast, it's got a tiny footprint, and it encourages a new way of working in component-based architectures. That being said, it gets a lot of hate in the Frontend community and it's easy to see why.
The problem
Followers of traditional HTML-CSS-JS workflows complain that it works against the principles we have all followed for the past 10-20 years of web development. Keeping all your styles in one place makes sense, and makes life much easier when it comes to maintaining a frontend. If you use a methodology like BEM, you can understand where the styles for a component will be just by reading the class name.
When we add Tailwind into a traditional frontend, every one of these principles goes straight out the window. Styling is no longer confined to one area or file type - it's split between CSS, HTML and sometimes even JavaScript. We might change a CSS property, only to realise there's a Tailwind class that overrides it completely. All of this leads to a mess that is difficult to understand and maintain. The choice between the two approaches should be either-or: No mixing Tailwind with CSS.
So it Tailwind actually bad?
Tailwind, just like regular CSS, can work beautifully if used correctly. As is often the case with styles, the issues start to appear in droves as soon as we misuse the technology and ignore the rules that keep developers sane. Poorly written CSS is just as confusing as misused Tailwind.
This technology is still in it's early stages, but I'm a huge advocate for Tailwind and have used it in quite a few different projects. I've written more about why it's so good, and particularly how to use it, in my other articles:
Top comments (1)
Thank you for the heads up. I am preparing to learn Tailwind. Now I am a little bit more informed.