This is Tiny Improvements. I'm Mike by ko I hate Tailwind CSS. Here's why I use it. In the first days of building craft work, I made the decision to use tailwind CSS for our projects. This choice was driven by tailwind's, adaptability, and its popularity among developers. Here's the thing, though, tailwind and I don't really get along. I've spent years learning to create design systems with traditional CSS.
More recently, I found myself building products using full blown UI libraries like Material UI because they make it super fast to build a rich, functional, and accessible ui. By contrast, tailwind is somewhere in the middle of these two things. On some level, it bypasses the nuance to understanding and control that came with writing raw CSS.
It's also not fully functional outta the box like material UI or chakra are, and yet for so many reasons, it's really good for us Tailwind provides some huge benefits. For example, speed tailwind's. Utility first approach allows us to quickly implement designs without having to write custom CSS. This is especially useful when we're iterating on designs and need to make changes quickly. Universality at Craftwork are Stack includes Ruby on Rails next JS and React native tailwinds.
Flexibility allows us to use the same styling system across all these platforms, which is a huge win. Talent Craft work isn't just me and it never will be tailwinds. Popularity across the industry has made it almost trivial to find developers who are familiar with it. This is a huge win for us as we grow our team. UI Libraries due to its popularity. There are many UI libraries that are built around Tailwind, including Tailwind UI Shad, CN UI, and ACE Eternity. UI. Costs to license.
Each of these libraries vary. Some are even free, and they're essentially copy pastable components that you can use to build your products. That's very cool. What this means for us in practice, tailwind's. Adaptability is what really shines from day one. It has enabled us to onboard new teammates and build interfaces more rapidly. It's consistent utility across our entire stack means that regardless of the project, new team members can quickly read, understand, and contribute to the code base.
The decision to use tailwind therefore wasn't just about adhering to current trends or sidestepping the complexities of raw CSS. It was a strategic move to ensure our team can hit the ground running, maintaining agility and coherence across our diverse projects. This underscores a more important principle in tech selection. Aligning tool choices with team dynamics and project requirements is a skill.
It's a delicate balancing act, weighing the benefits of technological efficiency and team scalability against the richness of personal expertise and the depth of traditional craftsmanship. It's a reminder that our growth as developers is not just about keeping up with the latest tools or getting entrenched in what we already know. It's also about valuing and honing our foundational skills. Put another way for everything we build. We have to balance velocity and quality.
Tailwind is a tool that gives us wins in both columns. All that being said, I do still have a wishlist for tailwind. I'd love to see better tooling tailwind's approach to utility first, CSS is great for performance, but it also means that we have to configure tailwind to compile per project so that it only includes the styles we use. When this infrequently breaks, it can be difficult to detect and debugging. It isn't always straightforward. I'd also like to see better IDE support.
Tailwind provides a consistent language for styling our apps. There are plugins for VS codes and tele sense that make it easier to write tailwind classes, but it doesn't always work. This can make it difficult to remember the exact class names for certain styles and can slow down our development process. Prettier, prettier rules. Adding tailwind classes to HTML means that we often have long lists of class names added to our HTML.
This causes individual lines of code to be very long, despite what many engineers will tell you, this is demonstrably worse for UX than having class names listed on separate lines. There's lots of discussion about building a prettier rule for this, but as far as I've seen, there's not a great solution yet. So in the end, do I really hate Tailwind? Well, no, of course not.
I've come to appreciate it for what it is, a pragmatic choice that has helped us build better products faster, and that's something I can get behind. I had love to hear from you. What are your thoughts on Tailwind? Do you have any tips for using it more effectively? Is there a UI library you love that I missed? Maybe you have a wishlist of your own. Let me on threads at irreverent mic.
