As web development continues to grow, we have seen the rise of three very popular frontend frameworks: Angular (formerly AngularJS), React, and Vue. Most web developers have at least heard of these frameworks, even if they haven’t worked directly with them. While this article won’t dive into the features and characteristics of each, it is important to note one major similarity between all three: components play a central role in using them.
When building a component to use in one of these frameworks, developers usually start by creating the structure of the component before “filling in” the content or values of specific attributes based on specific rules and logic. While building the component, developers will face a smaller, apparently innocuous challenge: naming the CSS classes they will need to style the component.
It seems simple. However, experienced frontend developers know that maintaining CSS can be an absolute nightmare the larger a project grows. Poor naming conventions contribute largely to this issue – it can lead to someone “borrowing” a class to use its styling on a specific element and then overwriting part or all of the styling on a different class. Making changes in the CSS can have a cascading effect (pun intended), where you’re suddenly affecting things you never realized you would.
In an attempt to combat this, there are a large number of naming conventions out there. For example, the Block-Element-Modifier (BEM) methodology is highly popular, and can be quite effective once you get used to it. Bootstrap is a framework based on pre-built components which you can then extend and alter for your own purposes. Neither remove the risks and issues mentioned above, but rather attempts to make it easier for developers to create stylesheets without unwittingly causing those issues.
TailwindCSS offers an alternative – Utility First CSS.
TailwindCSS expands upon a feature found in Bootstrap – utility classes – and cranks it all the way up to 11.
TailwindCSS has a long list of utility classes – that is, classes that only handle one specific property in CSS. Whereas Bootstrap uses components such as “btn” to assign several properties to an object, Tailwind would use several utility classes to style the element, like so:
<a class=”btn btn-primary” …>
<a class=”p-6 max-w-sm mx-auto bg-white rounded-xl“ …>
Now, this looks a bit grating, I’ll admit. But the reality is that while this does increase your HTML markup, it provides you with several advantages.
Everything is highly customizable, the amount of CSS you need to add or modify is minimal, and there is essentially no risk of disrupting other elements in your project because you needed to modify something, to name a few. Since there is a plethora of predefined utility classes, you’re usually working with a pre-defined styling system, which gives your site consistency and removes the burden of choice from you when starting a project from scratch.
But what about responsive design? What if I need specific values? No worries – Tailwind also has access to responsive utilities so you can apply different styles for whatever breakpoint suits your needs, as well as being highly customizable – want to make sure padding changes based off 1.5rem rather than the default? Need to add a specific font-size for a singular component? It’s all covered.
In particular, Tailwind’s utility-first approach is very well-suited for creating components in one of the previously named frontend frameworks. You can add or remove specific utility classes to a component based on whatever logic you so choose without having to create multiple states for a given class name. By working on a component template, there is only one file to modify to change the way each instance of the component looks like, and you don’t have to worry about complex selectors, precedence, or accidentally breaking a different element that happened to share one of its classes with this component.
This isn’t to say you should forgo abstract class names entirely – you can and should combine utility-first CSS with reusable classes in CSS, but you should keep these latter ones to a minimum – such as when you need to handle complex animations or if you end up with a pattern that you reuse constantly. This way, you avoid abstracting your styles ahead of time and end up with only the abstractions that you truly need to reuse – no more coming up with styles for 15 different “__wrapper” elements for different blocks; you can focus on adding the styling directly to the element and making small adjustments there.
This article barely scratches the surface on all that Tailwind CSS has to offer. I recommend checking out the official site to find out about what the 3.0 version brings to the table, as well as detailed documentation that covers installation with popular frameworks, using Tailwind in conjunction with PostCSS, all their utility classes, customization, and much more.