Tailwind 2 is all the rage now. With a beautiful landing page, promising productivity, and thousands of people swearing by it, could Tailwind be the future of front-end design? I am still not convinced.
What is Tailwind? Tailwind is a Tachyons school of thinking that preaches the utility-first approach to CSS. Whereas frameworks like Bootstrap and Bulma give you basic styling, pre-designed components, and utility classes, Tailwind gives you only the utility classes that you can combine to components yourself with just HTML extraction.
There is a lot of praise published on Tailwind – and some critics as well. I don’t feel like repeating it. Rather, I will make this post about my personal experience. I will tell you why I avoided Tailwind, why I gave it a try, my first experience, and my final thoughts.
Why didn’t I try out Tailwind sooner?
I am not a CSS guru, but I can write stylesheets for my use-cases. I depended on frameworks like Bootstrap and Bulma for application development or plain old vanilla CSS for prototyping and small sites. But above all, I am a developer that doesn’t depend on a build system for his styles and JavaScript. I didn’t work on fully separated components in my own work.
This brings me to the reason why I avoided Tailwind. I didn’t want to depend on a build system to ship a few styles for a landing page. You can try Tailwind without it, but you cannot ship Tailwind in the same sense of shipping Bulma due to its size. On top of that, I thought having a lot of classes is ugly and pollution for your templates.
I completely understood that adding a small configuration to Webpack for Tailwind and keeping the long class names inside components is not a big deal if people use it together with React components. But building a plain Jekyll site without Webpack? Not as cool.
What brought me to try Tailwind in the end?
I decided to rework Deployment from Scratch landing page. It’s a small scoped redesign of one page and thus ideal to try new things. I was also thinking about trying Bridgetown, a Jekyll fork with Webpack integration out of the box. If anything wouldn’t work as I wanted, I could be back to vanilla CSS in no time.
But why did I even want to try it? I think I was quite impressed with the design of the v2 landing page, how fast the design process can be, especially considering responsivity. Classes like sm:hidden looked like a nice productivity boost. I wanted to know if what people say about Tailwind can be true. If it can be a little bit less messy in the end despite the long classes.
How did it go?
I think that the start was pretty smooth since Bridgetown has Webpack support built-in. The main issue I had was reusing the parts of the landing page I already did in CSS. It was pain. I couldn’t easily combine my existing CSS, which completely fails the “Tailwind for prototyping” use-case. Yes, I know about @layer utilities {}, and I pushed through.
Then I had to make a security checklist for the book, and I thought hard if I should use Tailwind. I didn’t. I skipped Tailwind because it was just one page again, and with Bulma, it could stay this way. After I finished the security checklist, I looked again at the mess of the new landing page I made. And I didn’t like where this was going. So I have a half-finished landing page and think I’ll just start again with custom CSS or Bulma.
I started to write this post to be published after that homepage redesign is done, but there is no point to wait any longer. My experiment failed. As with every shiny new thing, it’s good to sit down and evaluate it for yourself. Tailwind did not impress me, but I do not completely oppose it either. Maybe I should try again as part of the PETAL stack. If you are evaluating Tailwind, also read previous art of Tailwind criticism.
