Tailwind CSS— A recap after two and a half projects
Tailwind CSS— A recap after two and a half projects
Tailwind created a lot of hype recently. But with all the hype there, of course, comes plenty of backlash as well. What are some of the critiques Tailwind is facing? And how did they hold true for me — a full-stack developer that likes the backend way more than the frontend?
About two years ago my sister decided that she wanted to start her doctor’s ordination. The supportive brother I am, I offered her to make a website. Or at least implement a design that somebody else created — I am a really bad designer. After getting the design I sat down to evaluate my options on how to create a website these days.
WordPress sure is a big option for such a small website but, honestly, it still felt a little bit too big and clunky. Therefore, I settled with hugo and created a small JAMstack side.
Since then, I have used this design framework in two finished projects and one that I am still working on. I really love this system because even I can design a UI that is not ugly and doesn’t look absolutely “Bootstrap generic”. Also, it is easy enough to make the website/web app responsive as well. After reading some critics on Tailwind I decided to write up my response to it and explain why I think most of these are not valid — at least for my use-case.
Critique # 1: Tailwind CSS pollutes the HTML
For the first two projects, I used plain Tailwind CSS without any other tool. I used the utility classes in my HTML which indeed made the semantic of a certain element unclear. But it worked! And it was really easy to mitigate this problem.
I created partials/components with a meaningful name. This way the semantic meaning of a certain element is clear and the look is defined in a single place. When I wanted to change a small detail I just adjusted the file there. I also made it possible to overwrite some parts of the design so that I can adjust how it looks for a certain place.
In one of the critics I read, the author said that this solution will create other problems like prop drilling. (Passing down a property to all the components until it is finally used) In my opinion, this is an invalid critique. If you decided to use a component-based framework like React, there always is a solution to this problem — React has hooks and also Redux. And when you use such a framework and are not using a component, then you are really missing out and shouldn’t have used it in the first place.
In my third project, I added daisy ui as well. It gives me a few predefined elements and I can adjust the design very easily. But right now, it is too early for me to say if I like it more with this framework or not.
Critique #2: Tailwind CSS makes you forget CSS
As mentioned in the beginning I really don’t enjoy doing frontend stuff. Therefore I didn’t understand the flexbox model when I started to work on the website for my sister. But since this model makes so many things a lot easier I had to get comfortable with this as well. And I did. It didn’t hinder me at any rate that I used Tailwind, I even think that it made it easier for me to understand a few CSS concepts better because I really had to use them instead of just using some “semantic” CSS class that other frameworks offer.
Now I think of Tailwind as an easier CSS API. Something like jQuery used to be for the DOM API/XHR API, when it really lacked features and was so different for various browsers¹.
Or, to use another comparison, it behaves like ActiveRecord does to SQL. Many argued that with ActiveRecord you don’t have to know SQL but this isn’t true. Of course, you can write an app without knowing SQL but it will make it very hard for you if you don’t know the concepts. And when you want to learn SQL ActiveRecord helps because you can read the SQL it generates and see how it works. And then, if you know SQL, ActiveRecord is still so much more convenient to use. And if you need the power of plain SQL it is there for you as well.
Critique #3: Tailwind CSS destroys the Cascading
Another critic is that Tailwind is destroying the cascading. This might be true. But I really personally don’t like it when there is a lot of cascading happening on an element. This feels like a deep object-oriented class hierarchy. It is powerful, but it makes it easy to mess things up.
When I have to debug a UI glitch at work I always wonder where a certain design comes from. And when I find the problem I often have to overwrite the attribute for just one element anyway.
But this might be a different experience for you. If you really know CSS and can handle the complexity the cascading is adding this might be a real pain for you.
What I have to say after two and a half projects using Tailwind is that it is a perfect solution for my use case and with my skill set. It helps me to create a web app with ease which is exactly what I am looking for in a CSS framework. But please remember that I can not speak for big projects (yet) and I am not really into frontend design at all.
¹ The CSS API, of course, works similarly enough on different browsers today, but I used this comparison just for the way it feels to use Tailwind and how it increased my development speed.