Why we chose Tailwind and other contentious thoughts
This has been hashed and rehashed everywhere so I'm just going to add to the noise and not apologize. We chose Tailwind.
We're a small team building web apps for clients and a Virtual Events platform. Our clients don't usually know what is possible and they don't usually have a 100% solid idea of what they want.
David and I had several requirements we needed to solve as we began working together. We hadn't articulated this fully at the time, but the advantages of using Tailwind for a small agency became apparent as time progressed.
We needed a common language
When you really get down to software development fundamentals, all you are doing is describing to the computer what to do. There are a thousand ways to do this and as a single developer, it doesn't matter so much what you use as long as you are productive. (That word is loaded)
The second you start working with others, your bullshit code becomes friction and can really delay slow down your project's velocity. So it becomes imperative to have a common language to speak.
How I think about HTML & CSS
I'm sorry in advance for waxing poetically. I like to think of HTML as a landscape. No, not some expressionist landscape. Hmm 🤔.
HTML is like a landscape in the sense that there are features to it. There's a structure. That same structure can be styled a billion different ways. (BTW, csszengarden.com still exists)
CSS is more like the properties you see in the landscape. Color, size, orientation, space, light, depth. These can all be mapped to CSS properties as they can be described to a person viewing that expressionist landscape I decided not to use.
In order to work together with n > 1 developers, you have to have that common language to describe your landscape.
The expressionist landscape has stuck now.
Tailwind is our common CSS language. This has ensured we did not have to create that common language ourselves, helped us maintain our velocity, and has eliminated context switching between styles and HTML.
Not writing our own common language
This is huge. This is probably the biggest piece. We did not have to write our own common language. We have an agreed-upon way of describing the interfaces we want. We will only argue about what is being said and not what words we use to say it.
There's a common saying in software development, "Don't repeat yourself" It's something I aspire to, but I have extended it. I try not to repeat others as well.
Tailwind has over 4000 commits at this point. The number of developer hours that have gone into the product are lightyears away from what David and I could achieve writing our own CSS framework.
Maintaining your velocity
So what we do has changed a lot this year, but essentially we're working tightly with companies making new projects. They don't always know what they want, they don't always know what's possible. They do know how to describe what is valuable though.
Our first job is to do a fair bit of exploratory work ideating with their team, and this requires rapid iteration. Tailwind helps you manage that as you have access to Utility classes right in the context of what you're building.
Less context switching
This brings me to my next point. I hate context switching. That really slows down my productivity so the more time I spend closest to the code that actually changes what I'm building the better.
The Utility classes go right in the HTML and I couldn't be happier with it. The shared language means I can immediately read what David has written, and at least can guess what he was aiming at. That's about as far as you can get without discussing what the aim of a UI is supposed to be.
If all I had was the CSS class name, I'd have to do a search in the codebase or the browser for what was done to achieve the UI.
Speaking of UI
We're also using TailwindUI to iterate quickly with clients. Often we end up switching off the original designs, but it really helps to get the client's eyes on a well-designed base interface to talk about the interactions they want in their product.