CEO doesn't care about your CSS strategy, as long as you use Tailwind

For me, it's the epitome of "Don't knock it until you try it."

(Close second is TypeScript. Which was less that I found it revolting, and more that I didn't understand the point properly.)

I think, of every developer I know the arc has always been the same (with the exception of 2 who still don't like it):

  "Wtf is this, this is the worst thing I've ever seen."
  "Yeah but like, just TRY it though. Write ONE app in it."

Tailwind took the "Java/Go" approach of standardization and top-notch IDE integration + Dev workflow. You don't have to think about anything, because it's all been thought out for you, yet not in a way that's limiting (bunch of tiny composable pieces and allows you to go outside the "happy path" defaults if you want).

Looking back at the start of my career, it now seems caveman -like that you would onboard on to a project, and they would each have these massive CSS files with class names that ONLY had meaning to that particular project + were entirely subjective. And transformed over time, too.

Sure:

  <section id="landing-page-banner" class="panel secondary">

With Tailwind, WYSIWYG, and it's all fully autocompleted + gives you color previews inline and helpful visual cues for positioning etc.

I'm sure something better will eventually come along, but Adam really nailed it with this one as far as I'm concerned.

Signed,

Former Nonbeliever

I don't do front end, no dog in this fight. But when someone starts talking down to you, explaining in small words why "business is ultimately in charge", you know they lost the first argument and are now threatening to tell Mom on you.

- In addition to knowing CSS you now also have to learn all the Tailwind class names that map to CSS styles.

- Development starts fast because you just drop Tailwind’s utility classes into HTML elements but then you end up with a long list of classes and things become unreadable, and worse, you have to repeat yourself if you want to apply the same style to other elements. Better group the list of Tailwind classes into a custom class. Wait, we have just re-invented CSS classes but need additional build tools.

This is despite the fact I also think tailwind is the right choice, and I'll be living my life as if tailwind is the modern replacement for bootstrap.

> Tailwind has large (200kb) JS payloads

My tailwind deployment is 7kb css (before gzip+min) and 0kb js (0 files).

But that aside, there are known studies that statistically speaking, users leave if your page is slower.

> Senior leaders care about cost, not artistry, when assessing technical decisions

so we'll continue using the thing that existed before tailwind, then? I think my CEO would get mad and fire me if I rewrote all my bootstrap stuff into tailwind.

I would really like to read articles that give strong arguments in favor of using tailwind.

In my experience, Tailwind is great, and improves productivity, IF you are building an SPA with a modern javascript framework like React, that uses "components" as the primary UI abstraction. In that context, utility classes make a lot of sense.

But if you're doing traditional static content with semantic markup, then the traditional CSS stylesheet is still the better abstraction, and tailwind hurts developer productivity.

Here's a story: Two railroad engineers are tasked with blasting an opening along the edge of a cliff. The senior engineer says it will take thirty sticks of dynamite. The junior engineer says it will take ten sticks of dynamite. They debate it for hours without coming to agreement, and ultimately it's the senior engineer's decision to make. So the junior engineer goes to management and says, "This guy doesn't get it. He goes on and on about geology, and pressure waves, and cliffs he has blasted before, and his precious sticks of dynamite. But me, I understand that the purpose of blasting this cliff is to build this railroad on time, and that's why I say we should use ten sticks of dynamite." So management orders the senior engineer to use ten sticks of dynamite.

The blast fails, construction falls behind, and management is plagued with worries. Management ruminates on the failed blast and the two engineers, and remembers that the junior engineer was concerned about the construction schedule. "That guy had his head in the right place. He understands what I'm going through! If I had somebody like that in charge, I wouldn't have these troubles. The senior engineer is just concerned about his goddamned rocks and dynamite. No wonder we're not on schedule." So management fires the senior engineer and promotes the junior engineer to replace him.

It's an important lesson for developers to consider. If somebody runs to Mom, you have to go with them and make your case. If they are allowed to frame the problem for management, it won't matter whose technical judgment is vindicated in the end; management will remember them as the one who had their priorities straight.