In a modern spin on the Luddite revolution, some prominent software developers have developed an irrational aversion to TailwindCSS, for 'technical' reasons.
While the Luddites argue about memory footprint and syntactical purity, their bosses are focused on labour costs and developer productivity. The bosses are right, and the Luddites are wrong.
As developers, we build technology to serve a business or social function. Who cares if a tool is 'slower', or 'uglier', if it is better at solving the ultimate problem? The anti-Tailwind crowd is asking and answering the wrong questions, and likely making impaired decisions for their organizations.
Simply put, Tailwind makes existing developers more productive, and it turns non-developers into developers. It's just great. If you're not already using it, start now.
Why should you care what I think?
My name is Ajay Krishnan. I've been programming in Java and Ruby for 20 years. If you're into credentials, I have a BEng (University of Toronto, 2004) and JD (University of British Columbia, 2011), and soon I'll finish my MBA (McMaster University, 2023).
I've been a part of, literally, 100s of technology teams. I've been the team idiot, the star coder, the dev manager, the department head, and the senior executive. I have sent Integration Test Email #1. I am qualified to write this article because I have made some truly awful technology decisions in my career, and I'd like to save you from that fate.
Developers have the power—let's use it wisely
The good news is this: today's software developers are more sophisticated, better resourced, and better compensated than ever. The industry is becoming more diverse and inclusive. Developers are now empowered to take ownership of technical decisions.
The bad news is that software developers are squandering their clout, by refusing to bridge the technology–business divide. For many devs, every discussion about technology choices devolves into a discussion about computational performance. It's a pattern I have seen play out over and over again, in every industry I've been in—banking, food and packaging, cannabis, and biotechnology.
Case-study: A typical anti-Tailwind rant
I don't mean to pick on Jared White, but he is needlessly reductive about his dislike for Tailwind. Here's my attempt at a summary of his concerns:
- Tailwind promotes "ugly-ass HTML" and "div/span-tag soup"
- Tailwind promotes vendor lock-in if you use the
- Tailwind doesn't leverage the latest standards, like web components
- Tailwind has large (200kb) JS payloads
These are interesting technical points for discussion, but here's the thing: the person controlling the budget doesn't care if the JS payload is 20kb or 200kb, unless it hurts conversion rates (it doesn't—can a typical user even notice the difference?)
Nor does your CEO care if your code is "ugly", or if you eat your soup with a div-spoon or span-fork, unless it hurts developer productivity (Tailwind improves productivity, in my view—see below). And if you start talking about web components, your executives may jump on the table and start looking for spiders.
Senior leaders care about cost, not artistry, when assessing technical decisions
If senior management doesn't care about the size of the JS payload, what does it care about? In my experience, there are only two questions that matter:
- Will this decision improve the company's sales in the long-term? For most software-as-a-service applications, this translates into an assessment of UX and website performance.
- Will this decision affect the company's expenses in the long-term? For most software-as-a-service applications, this translates into an assessment of developer productivity.
Tailwind is the correct 'technical' answer to the correct 'business' questions
Let's revisit the Tailwind analysis, this time answering the questions that matter to leadership:
TailwindCSS won't affect sales per se. If Tailwind is used in spirit in which it was was authored, customers wouldn't know, or care, about Tailwind. Users are not sensitive to minor variances in JS payload, which are noise in the context of network latency. Users are just fine with terrible HTML that renders cleanly to the human eye.
Assessing productivity is where it gets tricky, because everyone's experience is anecdotal. Jared used Tailwind on a major project and didn't find a benefit. He's smart, and experienced with CSS. On the other hand, I've found that most junior and intermediate developers struggle with CSS, and it's more efficient to train them on CSS concepts through the Tailwind lens. This productivity benefit far outweighs any technical impairment due to the 'ugly' code they have to work with.
But the biggest advantage of using TailwindCSS is that it immediately makes a whole bunch of non-technical resources productive on the project. You'd be amazed what a motivated junior marketing or sales resource can do over a weekend with Tailwind Play, which has the downstream effect of freeing up designer and developer cycles to do even heavier lifting. It's a beautiful, virtuous feedback loop.
It's okay for technology to answer to business decisions
Ultimately, software developers need a thriving business to build amazing software that lasts. And this means business factors will, and should, trump purely technical considerations.
In the short term, a software business can operate at a loss, if it has enough cash. In the medium term, a software business can operate inefficiently, if it is profitable. But in the long term, a software business must remain more productive than other alternatives in the market.
And it's this productivity where Tailwind shines. It's a human benefit. And the Luddites are doing us all a disservice by reducing the conversation to the Network tab in Chrome Dev Tools.