Introduction to Tailwind CSS
Tailwind CSS is a utility-first CSS framework that enables building custom designs directly in HTML using pre-built utility classes. Instead of writing custom CSS per component, developers compose interfaces by combining small, single-purpose classes.
Core Philosophy
Tailwind is based on utility-first design, constraints, and composition. Small, consistent utility classes enforce a predefined design system and encourage composing larger UI structures without premature abstraction.
Comparison with Traditional CSS
Traditional CSS relies on semantic class names and separate stylesheet files, often leading to naming complexity and specificity issues. Tailwind places most styling directly in HTML, removes naming concerns, and avoids specificity conflicts through low-specificity utility classes.
Maintainability and Structure
Tailwind ties styles directly to markup, reducing the risk of unused or conflicting styles. Deleting HTML removes associated styling, preventing long-term CSS bloat common in traditional approaches.
Advantages
Tailwind enables rapid development, consistent design systems, small production bundles, and simplified responsive design. It is easy to customize and extend with themes, and collaboration is streamlined due to consistent class conventions.
Disadvantages
HTML can become verbose and visually cluttered with many utility classes. There is a learning curve, reduced separation of concerns, and potential difficulty managing large “class soups” without proper component abstraction.
Overall Trade-offs
Tailwind represents a shift toward composition and enforced consistency, trading initial visual elegance for long-term maintainability and faster development. While it introduces verbosity, it often results in more structured and scalable projects.
OK, so it's time that we tackle this horrendous looking UI. And the way we're going to do this is with something called Tailwind CSS. And you might have heard about it. It's a very popular CSS framework. What it is is basically a bunch of utility classes. So it's also known as a utility-first CSS framework.
that allows you to build custom designs directly in your HTML. So instead of writing custom CSS classes for every component or page, we compose our designs using pre-built utility classes. So you can think of it like having a comprehensive toolbox where each tool does something specific, and then we can also adjust these tools to our needs.
simply just combine a lot of small things to something bigger and then we actually gain a lot of flexibility to create modern looking UIs. Okay, let's dig a little bit into the philosophy behind Tailwind and the core philosophy can be summed up in three key principles and that is we have a utility first design. So rather than creating
semantic sounding classes like a hero or a card or an article card that we already have in our code base. Tailwind provides us with these small utility classes that does one thing or one specific thing and then we combine them to create something larger. It's also a constraint. We are constrained to these small classes that leads to consistency.
all of these utility classes that we get built on the same fundamental design principles so that we don't really have magical value. So if we increase, let's say, the space between two elements, we can go up a size or two and it would be consistent instead of us just saying like, I feel this should be a little bigger or a little smaller. We jump in
in sizes that is pre-known. And this leads to much more consistent designs across our application. The final thing is we use composition. We compose these small classes to create something larger. We also don't create extractions too early. It encourages you to write, or it being tailored, it encourages you to compose designs directly in your markup so we can extract components.
only when we start to see our pattern emerge, which is the same way that we write our Go code. So let's just quickly look at how Tailwind gave us from traditional CSS. With traditional CSS, we will have semantic sounding classes. Like here we have our author card, where we have an image element, we have our heading free element, we have a paragraph tag. All of them have semantic sounding names.
And then we would create corresponding classes in a separate file, where we again have offer card where we add some padding, some background color. We do the same with the little author avatar, right? We add some width, some height, and then continue through. So this is how we typically write CSS of how we did it traditionally, at least. Instead, Tailwinds approach is what you can see right here. We have the same markup or the same HTML.
We just use these little utility classes. So we have everything in one place. And we will also only style things in one place. We don't need to switch between files and we don't need to come up with file names or class names, sorry, which is one of the most frustrating things when you work with traditional CSS is simply to have consistent naming here.
Once you're used to Tailwind, you can quickly see, okay, what does these classes mean because you will write them all the time. So the key differences is that we have a different CSS file structure. In traditional CSS, we write styles in separate CSS files, and we try to use descriptive or semantic naming, whereas Tailwind has all the style, or at least most of the styles directly in the HTML.
We can still create custom styles in Tailwind as we will see, but most of it is going to be directly where it's used. So we can quickly correlate things with the markup and the styling of it. We also get rid of the naming issue. There's a lot of different naming philosophies that you can get used to, like something called BEM, for example, where with Tailwind, we skip this approach altogether.
are forced to stay consistent by using these utility classes. We also don't have to fight what is known as specificity. CSS will have different levels of specificity of what style to apply because it's cascading style sheets. So you can technically have a style one place and then have another, or sorry, a class in one place and then have that be overwritten in another place because that class
specificity is higher, so it's just being given more importance. With Tailwind, all these utility classes have low specificity, so it's very clear when we do overrides. It's very explicit and not something where you're finding the class that gets overwritten or why it gets overwritten. Also, we have
the thing that traditional CSS will grow over time and removing old styles can be risky because some might depend on it and some might extend it, right? With Tailwind, we know that when we delete some HTML, the associated styles are gone in the same way. All right, let's quickly look at the pros and cons of Tailwind CSS because even though I've mentioned a lot of pros so far, there is also some cons with it. The pros are
It's very fast to develop it. We have a consistent system in place, a design system in place. We get also a tiny production bundle because Tailwind exposes some tooling that we can use to minify our CSS. We don't need to struggle with finding the right names. It also made responsive design easy by exposing these classes to us that
we can use to quickly build responsive UIs. We can easily customize it. We will see how we can add our own themes where we provide some CSS variables to have, let's say, like some different background colors, some different suggest colors or error colors. And then by adding that to Tailwind, all of the other Tailwind classes also has access to our custom design. So it's very easy to extend and make our own.
It's also easy to collaborate with other people that knows Tailwind because the naming is so consistent. Right. What are the cons of Tailwind CSS? Well, our HTML will become quite verbose. We will add a lot of classes to this. There can also be a bit of a learning curve. There's a lot of class names to remember and conventions to remember.
It can be a little ugly to look at the first time you see it, right? We also deviate a bit from separation of concerns. Technically, styling is separate from markup. But we also get this thing where we change the things that should change together. I don't know if that makes sense. But if we change our HTML, we often will also change our styling. So those two should technically change together.
them changing together makes sense. We could have some issues with refactoring once we get these big, what's it called, class soups that can be very difficult to manage. But as we've seen as well, we can create components very easy with temples, so we can quite easily pull out things and just focus on creating good components with scoped classes that
only should affect these things. So we can mitigate most of these cons that come about when using Tailwind. So Tailwind, Tailwind CSS represents a fundamental shift in how we think about styling. Utility classes has been around for a long time. It's just they are the first one to really take full advantage of the approach. So we trade some
some upfront elegance for long-term maintainability and rapid development, as well as some built-in consistency. It is quite easy to jump into our, let's say, quote-unquote old project that I have using Tailwind for styling, because those styles are still the same. Those class names are still the same. We have to live with some awkwardness. We have to live with the class soup in our markup that can be, for some people, a big no-go,
I've worked on a lot of databases that uses Tailoring and it is often easier to have this force consistency instead of having a class names. It really requires a team that are disciplined in creating good sounding class names and that is not often the case. So we do get soup or class soup, but we do get projects that are maintainable in the long run.
