Subscribe to 💌 Tiny Improvements, my weekly newsletter for product builders. It's a single, tiny idea to help you build better products.

I hate Tailwind CSS. Here's why I use it.

I hate Tailwind CSS. Here's why I use it.

Thanks, I hate it

In the first days of building Craftwork, 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 and Chakra, 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. On some level it bypasses the nuanced understanding and control that come with writing raw CSS. It's also not fully functional out of the box like Material UI or Chakra - and yet... for so many reasons, it's really good.

For us, Tailwind provides some huge benefits:

  • 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, our stack includes Ruby on Rails, Next.js, and React-Native. Tailwind's flexibility allows us to use the same styling system across all these platforms, which is a huge win for us.
  • Talent: Craftwork isn't just me, and it never will be. Tailwind's 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 built around Tailwind, including: TailwindUI, ShadCN UI, and Aceternity UI. Costs to license each of these libraries vary (some are even free!), and they're essentially copy-pasteable components that you can use to build your products. Very cool.

What this means for us in practice

Tailwind's adaptability is really what shines; from day one, it has enabled us to onboard new teammates, and build interfaces more rapidly. Its consistent utility across our entire stack means that regardless of the project, new team members can quickly read, understand, and contribute to our codebase. The decision to use Tailwind, therefore, wasn't just about adhering to current trends or sidestepping the complexities of 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 but 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.

What I'd like to see change

All that being said, I do still have a wishlist for Tailwind:

  1. Better tooling: Tailwind's approach to utility-first CSS is great for performance, but it also means 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.
  2. Better IDE support: Tailwind provides a consistent language for styling our apps - there are plugins for VS Code's Intellisense 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.
  3. 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.
Screenshot of tailwind css code resulting in lots of long lines of code, causing horizontal scanning issues
Like it or not, a horizontal list of classes is more taxing than a vertical list would be.

So in the end, do I hate Tailwind? 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'd 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 know by replying to this email.

What I'm thinking about this week: Watching experts work

🎶 A musical savant showcasing mastry

There's something extremely satisfying about watching someone who's really good at their job do their thing. I've been sharing this video of musical composer Jacob Collier using Logic masterfully to compose a song in real time. There's such a beautiful confluence of skill, creativity, and deep understanding in this video.

The best creative tools make superusers shine, and I think that's something we should all strive for in our work.

🔌 Plug kinda nerdy, but he chill

I was pretty deep in the YouTube rabbit hole when I came across @AllThingsOnePlace. This is an electrical engineer whose videos are all about analyzing and reviewing power supplies and other electrical components. I promise it is way more interesting than it sounds. I had no idea that you could measure the quality of power coming from a USB charger!

More from me

🎙️ Every business is an API business

In my recent podcast interview with Allan Knabe from Apiable for APIs You Won't Hate, we dicussed how Apiable is building an API Portal service that helps API teams to create, secure, market, and monetize API products. Catch it on the APIs You Won't Hate feed here), or wherever you listen to your podcasts.

🎥 I've been more active on YouTube

Over the past month or so, I've gotten back into live coding on YouTube on the weekends. I've also got plans to start publishing more dev tutorials and startup content. If you're interested in that kind of thing, subscribe to my channel to stay up to date.

Hey, one more thing: make sure you register to vote. It's important. Like, deeply, existentially important.

***

Thanks for reading Tiny Improvements. If you found this helpful, I'd love it if you shared this with a friend. It helps me out a great deal.

Until next time - be excellent to each other!

SHIP PRODUCTS
THAT MATTER

💌 Tiny Improvements: my weekly newsletter sharing one small yet impactful idea for product builders, startup founders, and indiehackers.

It's your cheat code for building products your customers will love. Learn from the CTO of a Y Combinator-backed startup, with past experience at Google, Stripe, and Microsoft.

    Join the other product builders, and start shipping today!