Thread by @frontendben

A huge amount of the anti-#tailwindcss rhetoric seems to focus around 2 points:

1. I'm an expert in CSS and can write it better than a framework.
2. If I'm not writing CSS anymore, then what am I actually doing?

Both of those points are deeply flawed. Here's why (a thread)...

Let's focus on that first point.

"I'm an expert and can write it better than a framework."

You're wrong. Let's just get that out of the way to start.

Writing CSS to achieve a design is only a tiny part of what makes 'good' CSS.

So what is 'good' CSS?

Good CSS:

1. Works with the cascade, not against it.
2. Is lean.
3. Is easily understandable.
4. Is maintainable.
5. Doesn't try to be clever.

Let's break that down into some examples I've seen in my 20 years of writing code, up to me being a Head of Technology.

1. Works with the cascade, not against it.

I've reviewed a lot of code in the time I've been a developer. A lot. Probably more than I'll ever write.

The number one mistake I see people making with CSS is trying to fight against the cascade.

That could be using elements & IDs to apply styling, rather than classes (don't ever do this aside from 'resetting' a browser's default styling).

Or it could be falling foul of point 5: trying to be clever, using complex selectors to do something a single utility class could do.

This introduces a multitude of nightmares, from having to create ever more convoluted and complex selectors to fight the cascade, through to making understanding how a style is applied to a DOM element almost as complex as understanding a university-level math equation.

Fighting against the cascade also prevents your code from being lean. Yes, you're right, the goal should be to write as little CSS as possible, but that doesn't mean just selectors; it means properties and values too.

Although it might seem counter-intuitive at first, utility classes are the most lean approach to writing CSS possible. For example, 20 utility classes will be smaller over the wire, than three 'semantic' classes thanks to the way things like GZIP and Brotli work.

On point three, you might think semantic CSS – e.g. .button – is more understandable than a class like mx-5. And on the surface it is. But let's think about it for a second.

If I see the classes applied to a button with Tailwind, I can see from the HTML exactly what is going on. If I see a class called .button, then I need to go into the CSS file and find it (and no, because of how complex you make your code, the inspector is often next to useless).

Not only do I need to go into your CSS to understand what's going on, I need to find *where* in your file structure (which is 9 times out of 10 unique to you) you've put the button classes & that's assuming you don't have a button class in a file dealing with cards classes.

Utility classes can be worse (if everyone did their own thing), but that's where the value of Tailwind is. Because it subscribes to Laravel's convention over configuration approach, once you've learnt the naming conventions on one project, you can understand any Tailwind site.

Removing the need to dig through your uniquely structured CSS project, just so I can understand your unique way of writing and structuring CSS (which I'll probably never need again), saves me and my team a huge amount of time. And time is money.

And that leads on to the next point. Easy to understand, lean, and simple code is maintainable code. And realistically, this should be your main goal (beyond functionality) for any code you write – not just CSS.

Unmaintainable code is the worst thing you can write (and yes, sometimes it's unavoidable). Why? It's expensive to fix, and it's expensive to extend. And when it comes to CSS, it's expensive to test, & it's expensive to SEO. MOST IMPORTANTLY, it's expensive to your mental health.

At the end of the day, the earlier rules are about trying to not be clever. It's about do what you're paid to do, as quickly and as simply as possible:

Build a solution to a problem.

Because you are not paid to code. You're paid to solve problem *with* code – i.e. point 2.

At the end of the day, if you follow these rules, the natural conclusion is a utility-CSS framework like Tailwind.

Tailwind works with the cascade, not against it.
Tailwind is lean.
Tailwind is easily understandable.
Tailwind is maintainable.
Tailwind doesn't try to be clever.

Now I know what the main counter argument will be. "But if I need to change the colour of my buttons, then I have to go through and find all instances of that class and edit them".

If that's a problem you're facing, you have far bigger problems than the CSS you're writing.

1. Change management
If it's because a client (or your boss) is coming in and is asking you to make a change at the last minute, and you're doing it, then you (or your manager) has fucked up big time.

This is one of the reasons designing in the browser is a stupid move. There's a reason that designing as you build is not a thing done in any other industry. Sure, if the client doesn't request any changes, it's quick. But that never happens. And making changes is expensive.

You or your manager should be getting design sign off and making it clear to your clients or internal stakeholders that once they've signed it off, there are no changes. And if you do need to make that type of change, it's a new project that comes with a cost.

If you're being paid to make that change, then big deal. Having to change it in your badly written CSS isn't easier or quicker if you're doing the next thing – utilising components and dynamic code.

2. You're not using components and dynamic code.

Seriously? Unless you're a junior, you have no excuse not to be using components (whether that is in something like Vue or React, or in a server templating language like Blade/Twig etc).

Hell, you can even do it in WordPress.

Having to change classes in hundreds of places isn't a failure of a CSS framework. It's your failure to follow best practices when it comes to coding views, templates, & partials, & making them dynamic.

Either way, both of the previous points are process issues, not code issues.

In short, Tailwind CSS is a great thing, because of the reasons listed above. Also, to those 'code-smiths' and alike who think they can do better because they are writing the code themselves. I want you to repeat after me:

YOU ARE NOT PAID TO FUCKING WRITE CODE.