It’s been a year since I started using Tailwind CSS for all of my client work.
I was inspired to write about it now because of something else that happened this week: I did my taxes. And while I understand why people post in January talking about how the previous year went, tax season tends to be when I finally get around to looking at the last year for my own business.
And my 2020 went a lot better than my 2019. In 2020, I started working four days a week and fewer hours per day. I also made more money and completed more projects.
This isn’t entirely attributable to Tailwind, but I think it’s part of the story, and when I started using Tailwind I didn’t think it would make any financial difference at all.
But let’s step back to 2019.
In 2019, I started getting more work than my schedule could accommodate, and I identified front-end development as my biggest bottleneck. Most of my work involves creating custom WordPress themes, but always as a secondary element of a larger development project: something like creating an ongoing import process from an API and making that data available via Elasticsearch-powered queries, as a representative example. But the front-end still needs to be built, and I felt I was spending too much time on work that is straightforward but time-consuming.
My solution in 2019 was to pay someone else to do it. I couldn’t find anyone in my network interested in converting designs built in Figma to HTML and CSS, so I contacted one of the more popular companies specializing in that kind of work and paid them to do it.
And this worked pretty well. I thought I would work with them again, and I started compiling a list of the things I wished they’d done differently so I could request a different approach in some areas next time. But the list kept getting longer and longer.
Then a month or two later I discovered Tailwind, though I can’t remember how. I just remember being skeptical: skeptical of CSS frameworks, skeptical of utility classes; lots of skepticism.
My skepticism of CSS frameworks came mostly from how opinionated I’ve found them to be in the past, and I’ve ended up fighting built-in styles and grid systems, trying to force my clients’ designs into a framework’s idea of how a site should be structured.
Tailwind avoids all of that by being completely agnostic regarding your design and how to build it. Using it feels like applying the same CSS declarations I would normally apply but in a different way (as opposed to starting out with someone else’s CSS rules and then overriding the ones I don’t like).
Which brings us to utility classes themselves. I don’t think I’m qualified to wade into this battle, so I will instead point you toward other people’s (sometimes intense) thoughts on the matter:
- Kiss My Classname by Jeffrey Zeldman
- CSS Utility Classes and “Separation of Concerns” by Adam Wathan
- Problem space by Jeremy Keith (responding to Wathan’s post above)
Keith concludes his post:
I very much appreciate the efforts that people have put into coming up with great naming systems and methodologies, even the ones I don’t necessarily agree with. They’re all aiming to make that overlap of HTML and CSS less painful. But the really hard problem is where people overlap.
I agree with all of this! I struggled with the idea of using utility classes throughout my client work since I respect Zeldman and Keith’s opinions so much.
But I still decided to try Tailwind, and I soon found it allows me to build websites more easily and more quickly. I work almost exclusively as a solo developer, so there’s no one whose work overlaps with mine; the places where people overlap all involve hypothetical future developers, and there’s a limit to how much more my clients are willing to pay to accommodate developers they haven’t hired yet. With Tailwind I can offer my clients faster turnaround times, both for the initial build and for future revisions. And I enjoy my work more because I spend less time on front-end work (which I also enjoy, but only in the right proportion), and the time I do spend on it results in fewer frustrating moments.
It takes me less time to start new projects because I never think about how to structure my Sass folders or what naming scheme to use for classes. When I go back to other Tailwind projects I’ve built, I immediately know where to find everything I need and how it’s built. When I’m working on a site’s front-end design, there’s almost no context switching—jumping from HTML to CSS and back again—and I don’t find myself struggling to think of appropriate class names and then revisiting them as the project progresses.
As an added bonus, Tailwind will drag you into modern CSS development (if you’re not there already) with their curated set of utility classes specific to things like the CSS Grid and Flexbox Layout modules.
So I’ve talked myself into it. And I think now I’m trying to talk you into it, though I didn’t know that was the plan when I started writing.