tailwind to the rescue.

July 23, 2020

Tell me: does this sound familiar? You go to your bug-tracker of choice with a few minutes left in your workday and pick a task off of the list that looks simple enough to do in just a few minutes. The task? Increase the padding underneath the title element on a single, specific page. Definitely not a hard change to make. So you open up the codebase, find your way to that line of code, and realize that the title element looks like this: <h1 class="title">Page Title</h1> .

Ok, not a problem, you open up your SCSS file (because braces > spaces) and change the padding-bottom property on the .title class. Perfect! Just as you're about to git push to the main branch and move on with your day, a little thought pops into your head. "Hey, you know that CSS class you just changed? Yeah, you probably ought to go back and check that the rest of the website looks ok because you might have just messed everything up." And sure enough, you go back and check all of the other places that use the .title class, and everything looks wrong now.

Ok, again, not a problem. Obviously changing the CSS was a bad idea to begin with, but now you have a much safer approach. Now, instead of trying to change something that would affect the entire site, you decide to make another class that will change how the .title class functions slightly. You pop open the SCSS file again and nest a class called .bottom-padding-3px inside the .title class styles, making sure to put everything in the right order so your new class styles will override the original styles in the .title class. You go back to the website and, perfect! The single title that you were tasked with changed has been changed, and everything else on the website has remained intact.

But you're not done quite yet. A few minutes later, you get a message on Slack from the web designer. They notice that you took the ticket about the title padding and wanted to let you know that they actually miscalculated the padding needed—they now want four pixels of bottom padding, not three. Again, not a problem. You pop open the code again and quickly change the padding-bottom property to 4px instead of 3px. Problem solved. Except now you have a problem. Now you have to go back and change the class name from .bottom-padding-3px to .bottom-padding-4px. All the while, having to wait for Webpack to recompile your assets folder so that you can see the changes.

For me, this is how styling a website went for YEARS. And these sorts of problems only get magnified when you take into account an application that has lots of bloated, out-of-date legacy styles and multiple teammates working on the same application at the same time. But, out of seemingly nowhere, a solution to this problem has exploded onto the web development scene. That solution is called Tailwind CSS.

let's talk about Tailwind

If you haven't heard of Tailwind CSS, prepare to have your mind blown. Tailwind CSS is a "utility-first" CSS framework (though, I don't think framework is the best word to describe it—more on that later) built by Adam Wathan and Steve Schoger that makes writing consistent, beautiful UIs easier than ever.

The first thing you might notice when you look at a project using Tailwind CSS is that there's an awful lot more text in the project's HTML than usual. And, on the flip-side, there's almost nothing declared in the project's CSS files. That might seem a little bit odd considering that Tailwind is a CSS framework; I know it seemed weird to me when I was first looking into it, but that is part of the power of Tailwind.

Tailwind is made up of a HUGE amount of utility classes by default, but you can override and extend those classes at will using the Tailwind config file (more on that later, too). Those classes cover most of the types of styling that a developer will be writing on a day-to-day basis, from controlling margins (.mx-8 ) to changing font sizes (.text-3xl). Each of the utility classes in Tailwind performs a specific function, which is great on its own but becomes a superpower when multiple classes are combined like building blocks! For example, the .title class from earlier in the post could look something like this if written in Tailwind:

<h1 class="font-sans font-semibold text-4xl uppercase mb-3 px-2">Page Title</h1>

In that one line of HTML, we've declared the font-family, font weight, font size, text-transform, bottom margin, and horizontal padding. The names definitely take a little bit of getting used to, but once you've committed the basic structure to memory, this code becomes extremely readable, even if you're quickly scanning the codebase to see what's going on.

tailwind isn't just a CSS framework

The Tailwind website says right there at the top of the page "Tailwind CSS is a highly customizable, low-level CSS framework that gives you all of the building blocks you need to build bespoke designs without any annoying opinionated styles you have to fight to override." Now, I'm not going to outright disagree with Adam and Steve on this one, because they're right—technically, Tailwind IS a CSS framework. But, I think there's a better way to describe Tailwind that shows off the true power of its utility classes.

configuring Tailwind

First thing's first, we need to talk about how to customize Tailwind. Right out of the box, Tailwind ships with a bunch of really helpful utility classes (I used a few in the code example in the last section), but if those styles don't fit the project that you're working on, Tailwind gives you a ridiculously easy way to override or extend the existing styles. Whenever you add Tailwind into your project, you also create a tailwind.config.js file in the root of your project directory that will look something like this:

module.exports = {
    purge: [],
    theme: {
        extend: {
        }
    },
    variants: {},
    plugins: []
};

There's a lot going on there, but for our purposes, we're going to focus on the theme object and its extend child object. Each utility in the framework has a corresponding JavaScript identifier, for example, the max-w-{} utility classes are mapped to the maxWidth key, that can be used to create overrides for the max-width utility. For example, compare the previous Tailwind config file with the following:

module.exports = {
    purge: [],
    theme: {
        maxWidth: {
            "1/2": "50%"
        },
        extend: {
        }
    },
    variants: {},
    plugins: []
};

Now that we've added a value to the maxWidth object, Tailwind will recompile and build out the utility class for max-w-1/2 that will add a value of 50% to the max-width property on whatever element the class is positioned on. There's an important feature to note here. Since I added the maxWidth key to the theme object directly, and NOT to the extend object, when Tailwind recompiles, all other max-w-{} utilities will be removed. If you'd rather just add the max-w-1/2 class to the list of max-width classes, we would move that maxWidth declaration to the extend object instead, like so:

module.exports = {
    purge: [],
    theme: {
        extend: {
            maxWidth: {
                "1/2": "50%"
            }
        }
    },
    variants: {},
    plugins: []
};

Now our max-w-1/2 utility class will live nicely right alongside all of the default styles!

back to the framework discussion

So now that I've left you on a cliffhanger, let's circle back to my statement from earlier. I believe that calling Tailwind CSS a "CSS framework" and leaving it at that does a massive disservice to the ingenuity that has been put into this project. Tailwind is much, much more than a simple framework.

Tailwind CSS isn't just a CSS framework; it is a CSS framework framework. I think the real power of Tailwind is focused around its ability to quickly and easily allow a developer to put parameters of a given project's design into code, which in turn will generate a project-specific framework, tailored specifically to the design needs of that project. Or, to put it more simply, finally, Tailwind CSS makes it easy to quickly write efficient code that matches the needs of a project's design.

final thoughts

There's not much to be said here except that I'll be using Tailwind on every single project I can from now on. Tailwind has already saved me a ton of time and stress and has made it even easier for me to design things from the ground-up that look consistent and professional.

So what do you think? Have you used Tailwind CSS before? What are your thoughts on the utility-first approach? Reach out to me on Twitter, and let's talk about Tailwind!

Join my mailing list!

No spam, just a weekly newsletter with thoughts, discoveries, and cool new things in the world of programming.

subscribe.