Tailwind does not save you from CSS

You aren’t learning anything valuable by learning Tailwind and you aren’t avoiding CSS either because you can’t use one without knowing a lot of the other.

There’s nothing in it that makes CSS easier or that hides the understanding you need to build things. Take a horizontal flexbox layout. Knowing display flex, flex direction row and flex wrap gets you there, and so does flex, flex-row and flex-wrap, and those two are functionally identical. You have to know what either set is doing before you can use it and there’s a one to one mapping between them so learning one means you know both.

That’s the whole thing. It’s a shorthand notation, and in a few places the equivalent of a macro. The arguments about whether it’s good or bad tend to skip past that and treat it as a different way of thinking about styling which it isn’t.

Learn CSS. That’s the part which will still be useful in twenty years and it’s the part that transfers to every project you touch regardless of what’s fashionable when you arrive. I don’t imagine Tailwind itself is going to last another twenty years and I do think people will keep using utility first libraries of some sort from here on. Nobody is going back to writing plain CSS by hand unless they have no choice about it.

The reason is worth being honest about because it isn’t fashion, and cSS keeps getting more capable and everything that gets more capable gets more complicated alongside it. What Tailwind offers is all that power with a less arcane syntax sitting in front of it, and once you’ve got that it’s hard to construct an argument for giving it up. That’s why it won and it’s a better reason than most winners have.

There’s a caveat I keep coming back to though. Tailwind is the CSS equivalent of jQuery and that comparison is meant as a compliment about its trajectory rather than a criticism of the thing.

jQuery was enormously good and enormously popular, and what eventually happened to it is that browsers absorbed the useful parts. The selector engine became a native method. The animation helpers became a specification. Everything people reached for it to do turned into a platform feature, until using it became a choice rather than a necessity and then a slightly odd choice. Nobody killed it. It got adopted.

Something similar is likely here. In five years or so a browser is going to ship a utility notation of some kind directly in the engine because the benefit is obvious enough that browser developers can see it as clearly as everyone else can. At that point the library becomes optional, and then it becomes a compatibility layer, and then it becomes a thing you find in old codebases.

So in one sense Tailwind will die and in the more useful sense it will have won completely which is exactly what happened to the last library that got this popular. Either way the underlying knowledge is the same on both sides of that transition and that’s the argument for learning the language rather than the abbreviation of it.

The practical consequence is about where you spend your learning time rather than which tool you pick for the next project. Time spent on the abbreviation is time spent on something with a shelf life, and time spent on the thing underneath keeps paying out through every abbreviation that comes after it.

Use whichever you like on Monday. Just be clear which of the two you are actually learning.