After a well over a decade of front-end development I thought I had CSS figured out. I even wrote a blog post about it called A Primer to Well-Structured CSS, where I explain how I stole smart ideas and combined them into a methodology that solved the problems that had haunted me throughout my career: I no longer had to worry about changing attributes and not know what it affected. I was no longer haunted by client conversations that went something like “hey, this thing over here is totally messed up — 😠 what did you do!?” No longer was I worried about handing-off a project to another developer and being embarrassed by my code.
Then I worked on a website with this Highlander named Curtis. Curtis is a developer, really smart, strongly opinionated, and — let’s not sugar coat it — quite anal about pretty code.
Curtis wanted to use TailwindCSS. I wasn’t so sure. Sure, I’d read about it, watched a couple videos about it, but I still wasn’t sure. The project we were working on had a speedy timeline, and I’d been burned before when trying new things on a deadline and didn’t want to repeat the experience.
More importantly, Tailwind went against everything I thought CSS was supposed to be:
- The idea of a stylesheet is that you can change things once and it will change everywhere; Tailwind makes you change the HTML, which means if you want to change the spacing between two elements, you have to do that everywhere the code is applied.
- Adding too-many classes to HTML just seemed gross. Bootstrap did it, and I always found Bootstrap a little 🤮 in that it was unwieldy and hard to control. I loved my clean, BEM style classes that had clear relationships; I didn’t want to lose that.
After agonizing for too-long over the decision, I was finally convinced by this quote:
“No joke, I’m at least 3 times faster at building UIs now.”
— Nick Basile, Lambda School, 5 Takeaways From Using Tailwind CSS In Real Projects
So I decided I would try it, and if it didn’t work I’d be quick to abandon it. But rather than abandon Tailwind, I’ve never not-used it since.
Why is Tailwind gud?
It is fast
First off, let me just say that I agree with Nick Bastile; I do feel like I’m building UIs three times faster. And that’s saying something, as in the past year I’ve spent less than 10% of my time coding. I imagine that if front-end was a full-time role for me that I’d get into a groove with Tailwind where I could feel like a console cowboy from Neuromancer. Slice me in, Molly.
I don’t have to name things
I love naming things. I was the kid that wanted to name all our pets. As an adult, to this day I keep a log of cool names for everything from companies to sports teams to bands to servers. But naming CSS classes is a chore. How do you describe a complex element in two words, while maintaining the flexibility of what that could be? Having to do that over and over is personally a huge bottleneck in my code-writing, and Tailwind eliminates that.
It’s not DRY — or is it?
One of the worries I listed above about Tailwind: I’d lose the beautiful feature of style sheets that allows you to change things once and change it everywhere. But it’s rare these days to come across a build that doesn’t use components. Sure, if I want to change padding between items I have to do that everywhere in HTML, not just once in CSS, but in reality that’s usually rarely more than a couple components.
On the flipside, what if I only want to change that spacing in one instance, not more than one? In the past, I would have had to create a new class — that can be technically DRYer than Tailwind if you use a modifier class, but it’s way more fun, and quite speedier to do it the Tailwind way.
I quit overthinking the design system
I’m a designer first, and like Curtis, I’m quite bit particular about my craft. I sweat hard over font-sizes and whitespace. When I managed my Star Wars fansite back in 2002 I had only one layout to worry about, but in our fully-responsive world I can get sweaty about the spacing between elements across device sizes. Tailwind forces me to chill-the-eff-out.
With Tailwind, I find myself treating components as “good enough”; rather than sweating about the one-off exceptions where spacing might need to be 53px instead of 50px, I’ll just lock it in at whatever looks close and be done with it for now.
This has the added benefit of making it easier when I’m not the sole designer/developer on a project. I’ll work early with my front-end team to establish the design system. After that, I don’t have to be pixel-perfect, because I can trust the Tailwind settings to align my designs to the exact spacing of the design system.
The problems I did have…
Most, if not all, of my issues with Tailwind seem to be resolved, or in the process of being resolved. When I first used it in January 2019 (I believe it was a pre-1.0 release), layout support using grid columns was a bit hacky, but that has since been implemented. Elements with transitions were something I had to revert to custom-built classes for, but that seems to be fully supported in a Tailwindy way now.
The team behind Tailwind seems to be identifying the high-priority issues well, and addressing them. That’s something that builds confidence in Tailwind as a methodology.
In Summary
The photography program at Columbia College (where I went for undergrad (but not for photography (I know you’re not supposed to nest parentheses, but now I’ve done it twice. #FLEX))) was pretty widely praised for teaching the fundamentals of film before the students went on to digital. In that vein, if you’re a bit newer to CSS I still think there’s a lot of value in understanding the work behind A Primer to Well-Structured CSS. It will teach you the fundamentals of CSS, and help you understand the mechanics of how CSS should work, similar to how learning to work with real film can teach you essential knowledge about photography before buying a DSLR.
But If you’re an advanced CSS Architect or Front-End Developer, I’d highly recommend giving TailwindCSS a go.
