My great friend Dani Cabal told us in his article Tailwind is to programming what the plague was to medieval Europe how we have traveled back in time to come back to the present and implement our styles as we did 30 years ago. 

But in this article I am not going to take you to the past but to the future, specifically to a future in which our style layer is well organized and structured, we have variables, utilities and encapsulated classes that help us to make our code more readable and cleaner. But don't we do this already? Don't worry, read on. 

«CSS? Where we're going, we don't need CSS.»

Back to the future

To travel to that promising future, we will not use a Delorean but something with more class, or rather classes. We will use Tailwind.

While there are fans and detractors of Tailwind, there is some consensus on the drawbacks of using it, but is it a strong argument that our code becomes unreadable and unreadable? Fortunately, we have tools to combat these drawbacks and make our styles more flexible and scalable. 

- But I already do what you say! 
- Wait and read on.

Reading and debugging problems

One of the main complaints about Tailwind is that the generated code messes up our HTML since a standard component can have dozens of classes even if it is a small component with only the necessary classes. Only taking into account the essential ones, the corresponding ones assigned to media queries and some other pseudo class, we have a good string of classes. Needless to say that returning to this component after some time to modify it can become a hard task, but do not panic, we have a solution to this problem.

This solution is none other than to encapsulate our styles, there are several ways to do it but I am going to focus on two in particular. The first one would be to encapsulate them in classes with @apply. This is nothing more than a css class that contains the Tailwind classes. 

.button {
  @apply bg-green rounded-l
}

With this and using the button class, we will have all the styles that we have applied, in this case bg-green y rounded-l

Another encapsulation solution would be to use a library such as class-variance-authority. With it we can not only extract our styles from the HTML but also control state changes and variants. 

Another common problem is style inspection in the browser. If we use Tailwind in canonical form debug becomes tedious, if we encapsulate styles with @apply We solved this problem, but not with class-variance-authority because the result is equivalent to adding the styles as classes in the HTML.

At this point we have solved the problem of having an endless string of styles as classes in the HTML and an improvement in debugging (if we encapsulate with @applyIsn't this a huge step into the future?

- I was already doing this with preprocessed semantic styles more than 10 years ago.
- Yes, but now you use Tailwind. Boom!

“What happens to us in the future Doc? Do we become assholes or something?” (Marty McFly).

Learning and mastering a framework

Another problem highlighted by Tailwind's detractors is how tedious it is to learn the more than 4000 classes it includes. Honestly, in our work as developers we are constantly learning and having to study a new technology I do not consider it a problem. Besides, in the end there are always classes that are more common than others and it is not complicated to find classes that implement less used properties. 

On the other hand, knowing a class means knowing all its variants. For example, if we know that p-4 equals padding: 1rem (based on 16px) we know that p-8 is equivalent to 2rem. 

If we know that the class rotate-45 is equivalent to transform: rotate(45deg) we know that the class rotate-60 equals to... 

-This... The class rotate-60 is not covered in Tailwind, it would have to be added to the configuration such that

extend: {
  rotate: {
    '60': '60deg',
  },
}

- Okay, what about the class p-15?
- It does not exist either, it should be added to the configuration as well.
- But my designer has put several paddings of 52px in their designs.
- Surely those spaces are a must. Or maybe they haven't had time to learn the 4000+ classes that you have learned and don't know that you have to add that spacing in the configuration. And keep in mind that the p-15 only affects the padding, if you want a margin of 52px  you must also add it to the configuration.
-Okay, I'll pass the course Make your own twitter in just 2h with Tailwind to the designers.

I insist, it shouldn't be a problem to learn how to use a technology, however...

CSS fades in time

After a year of intensive use I am struggling to remember the base properties of CSS and my knowledge is fading like Marty McFly when he couldn't get his mother to go to the enchantment dance under the sea with his father. When a new framework, I assure you that it will appear (like every Friday), I will have to write down all the properties that CSS has in an almanac to review it when the time comes.

“I guess you guys aren't ready for this framework. But juniors will love it.”

Conclusions

At this point it is time to consider the difference between encapsulating and organizing our style layer with Tailwind. vs Are we traveling several years into the future or back to the Wild West? It goes without saying that each developer is free to practice his work with the technology he likes the most, the one he feels most comfortable with or the one he is paid the most for. 

I find it interesting to think if we are really improving our stack by giving functionalities to technologies that are not intended for it. Tailwind tells us (in the header of its web page) that with its use we are going to build modern web sites without leaving HTML, just the opposite of what Tailwind's encapsulation approaches offer. Maybe our websites will be modern, but will we develop them slower and leaving HTML all the time? Only one thing is certain, “In my opinion, if you're going to do something like this, do it with style.” (Emmett L. «Doc» Brown).

Read more in our blog