5 Best Practices for Preventing Chaos in Tailwind CSS

Hi everyone. Today we're going to talk about best practices for using Tailwind CSS. My name is Nina. I'm a front-end engineer at Devilmartian. We're engaged in product development for large companies and startups, and we also develop our own open-source products.

Tailwind CSS is a popular and controversial tool. It balloons within developers into two opposing camps. Tailwind has become so popular because many developers love it for its convenience and for speeding up the layout process. But at the same time, there are developers who can't stand it, especially because of really long Tailwind CSS class lists. But the truth is somewhere in the middle.

For some tasks, Tailwind is extremely cool. We don't need to think about the name of CSS classes. And with a ready-made list of classes, we can build a project extremely quickly. But on the other hand, Tailwind is not a silver bullet. There are cases when it will just pollute the project with a huge list of classes as it grows.

After working with Tailwind for a long time, I have identified two main requirements where Tailwind is suitable, and without them, it's better to choose an alternative tool. And the first requirement is the project must have a design system. Tailwind is closely connected with the philosophy of the design system in which we use design tokens. Design tokens are atomic values such as colors, sizes or margins that are used throughout the project. If we use magic constants for the design properties everywhere, there is a high possibility that you can break something if you need to change a property, like a certain color, in all the places in the project, because you will need to search for a specific class in all your Tailwind class lists and replace it with another value. But if we use the design tokens, it becomes much easier and safer, because if we decide to change some design property, like a certain color, we can apply it in just one place, and it will be changed everywhere.

And the second requirement for using Tailwind CSS is that your project must have a component approach. The approach with CSS classes that Tailwind uses leads to verbose HTML structures, since classes are applied directly to elements. And if we can't encapsulate code into separate components, then as a project grows, the markup will become extremely difficult to read and maintain.

Here's an example of how the component approach works with Tailwind. Instead of copying and pasting a button like this everywhere with a large list of classes, we encapsulate it in a separate component and call it in one line.

Now, the good news is if you have a design system and a component approach, then Tailwind CSS may be a nice option for you. But to make long-term work pleasant and painless, you have to use this tool wisely and follow some best practices. The first, in Tailwind a long list of classes are a harsh reality, but this disadvantage should be mitigated by trying to use only those Tailwind classes that are necessary. Here are some examples of how you can reduce the number of classes and get the same result.

Instead of specifying the same margin at the top or the bottom, you can specify only a vertical one. Instead of specifying flex-row for a container with display value of flex, you can omit it with the same result, since flex-row is a default value of the flex-direction property. And in this example, we can remove border opacity 50 by adding a postfix with a slash in the number 50 for the border-black property. And this will be a shorthand for the RGBA format. So knowing these tweaks helps cut down the list of classes quite a bit while still preserving the same result.

So when working with Tailwind, if the list of classes has grown, ask yourself if you can somehow cut it down. Second rule while working with Tailwind is group design tokens and name them semantically. Group related tokens together in a config file, separating them into different sections, such as colors or distances. Structured config will be much easier to read as a number of tokens grows. Also, remember the importance of semantic naming and name your design tokens according to their purpose. For example, if the color is an error warning, don't name it just as bright red, name it semantically like error. Semantics like grouping make it easier to expand the entire design system as the project grows, so we should keep this in mind.

Rule number three, keep class ordering. Look at these two blocks. They have classes that are responsible for different aspects, display properties, box model properties, decorative properties and so on. But all these classes are specified chaotically and it's difficult to immediately say how these two blocks differ. But if we sort the classes, then this difference becomes more understandable and becomes easier to read such a list. It's better to automate the sorting work. I recommend using the official Pretier plugin for Tailwind CSS and it will automatically sort your classes.

The next advice for using Tailwind will be useful not only for Tailwind, but also when working with any content tools, monitor the bundle size and try to optimize it. Why do you need to monitor the bundle size? Because the average size of web pages is constantly growing and if 12 years ago it was like 800 kilobytes, then two years ago the average web page size was already more than 2,000 kilobytes. That's a big growth. And the larger the web page size, the longer it takes to load and the longer the load time, the greater the loss of users. Therefore, when using Tailwind, it's worth minifying the resulting CSS to optimize the build.

The last rule for Tailwind, use sets of style variants to avoid problems when overriding classes. Imagine that we have a button component on the page with a default white background. We are trying to override this class in such a way as to make the background black. But overriding the Tailwind class this way won't work and the button will remain white. Instead of passing classes arbitrarily via props, define a set of variants for the component.

Instead of passing classes arbitrarily via props, define a set of variants for the component. In this example, we declare two variants of the button, primary and secondary. And we can set the primary variant as default. And then when using the component, we can just specify the desired variant or not specify it at all to make it default. This will help make the appearance of the application more unified and also reduce the probability of visual regressions when changing styles.

That's it. Let's summarize all the best practices to make working with Tailwind effective and painless. Use fewer utility classes, group design tokens, and name them semantically. Keep class ordering, minimize your build size, and use sets of style variants. And finally, remember that Tailwind CSS is a very useful tool that can speed up your development, but you shouldn't consider it as the only universal solution for all projects. You need to choose and use all your tools wisely.

Thank you.