Why I choose Tailwind CSS

Why I choose Tailwind CSS

Early in my career, my focus was on HTML & CSS. When I was first introduced to Tailwind I was initially skeptical. However, using it in different projects, I quickly realized that the advantages outweigh the disadvantages.

Utility class approach

The main difference of Tailwind is the utility first approach allowing you to leverage predefined class names directly in your code.

Tailwind’s utility first approach is a major point of contention for those who prefer modular CSS. Initially I shared similar feelings. There is a sense of freedom that comes with creating modular styles by separating concerns. And lets face it, we are creatures of habit. Most people get paralyzed by this difference in approach and don't see past this point to understand how its one of Tailwinds greatest strengths.

The benefits of a utility class approach

Tailwind classes are tied to single or in some cases multiple CSS declarations. This allows the style sheet to only record declarations once.

For example, with modular styles you will declare declarations like display: flex or margin: 1rem repeatedly in classes where using Tailwind, declarations are recorded once in your style sheet reducing the overall size of the styles you need to bundle to the browser.

/* Tailwind - These two classes are reused every time you use these CSS declarations */
.m-4 {
  margin: 1rem;
}
.flex {
  display: flex;
}

/* Modular - We will find ourselves writing declarations more than once */
.MyClass {
  display: flex;
  margin: 1rem;
}

.MyOtherClass {
  flex-direction: column;
  /* repeated declarations: */
  display: flex;
  margin: 1rem;
}
/* Tailwind - These two classes are reused every time you use these CSS declarations */
.m-4 {
  margin: 1rem;
}
.flex {
  display: flex;
}

/* Modular - We will find ourselves writing declarations more than once */
.MyClass {
  display: flex;
  margin: 1rem;
}

.MyOtherClass {
  flex-direction: column;
  /* repeated declarations: */
  display: flex;
  margin: 1rem;
}

Tailwind does not repeat, therefore reducing bloated files and creating leaner style sheets. We can do more while writing less allowing us to move faster reducing the concern for how many styles we are using.

Over time enterprise applications are often susceptible to unwieldy style sheets and become to cumbersome to edit. Tailwind removes this problem by keeping styles coupled directly with the code.

Another point of contention is removing the need to handle CSS specificity. Tailwind will handle this for you and community solutions like tailwind-merge that allow you to focus on building your application and removing this complexity.

It's important to remember Tailwind is still CSS. If you want to write some code using specificity and custom classes you can and in some cases you should. I do this often, like when I deal with pseudo hover and focus classes on parent elements. I also frequently leverage the layer utilities function to create custom classes like styles for scrollbars.

Tailwind is merely providing you a framework of basic specificity to work off of and reduces complexity to make it easier for you and multiple others to work on an application together and be successful.

This is what good frameworks do, help you focus on the development of your application and alleviate the overhead of solving scalability and performance issues.

Consistency

The utility first approach makes it easier for users to adhere to standards with themes and systems. By providing classes out of the box, it is more likely that users of your system will stick to the conventions set by the team. When given the chance to write a new style sheet, engineers are more likely to try to solve a problem using unique values or different units and not sticking to variables and best practices.

Providing class names for engineers who may be less confident with CSS who may need to set layout or make small CSS tweaks, are more likely to be successful when they don't have to understand the entire ecosystem of style sheets to get their feature across the finish line.

Tailwind still provides flexibility to break out of any utility class and provide custom declarations:

<div className="grid grid-cols-[200px,1fr]">...</div>
<div className="grid grid-cols-[200px,1fr]">...</div>

Performance

Where Tailwind shines most bright is its ability to do the hard parts of performance for you. Without Tailwind traditionally when running your application against performance metrics, (especially large enterprise applications) you will likely have to determine which CSS is critical or above the fold. Typically teams have to create a solution to inline styles in the <head/> of the page and immediately hydrate the critical CSS. All of this is taken care of for you in Tailwind.

By default purging is built into Tailwind out of the box, further reducing the need to manually curate styles that need to be purged. Tailwind will purge all styles used in its base, components and utilities layers.

Customization

Tailwind supports endless customization, you can easily customize your configuration:

  • Specify files that use Tailwind
  • Themes
  • Screen sizes
  • Spacing
  • Colors
  • Typography
  • Countless plugins
  • Reusable presets

Anything you can do in CSS you can configure Tailwind to handle.

Prototyping

It is a tool that allows you to more rapidly prototype because you're given some presets that allow you to hit the ground running right away. Tailwind is great for prototyping but it is not bootstrap. Yes it comes out of the box unopinionated but the ability to customize it so heavily is there for you to form opinions on how the application should leverage it.

Large community and ecosystem

Tailwind currently has over 82K stars on GitHub and is actively growing. There's a huge community of support around this styling framework with many trusted contributors, active plugins and maintainers.

It's a first class citizen for Next.js which also has a large community around it, so expect Tailwind to continue to grow and be adopted as a framework.

Tailwind complaints

The biggest argument and longest running joke against Tailwind are the super long class names that can be created.

There are many techniques and approaches to managing this:

  • Using a clsx function to create arrays of strings to manage organization.
  • Creating constants and use them in your class names or clsx functions.
  • Using sorting mechanisms to reduce friction of class name changes.

This problem affords you the opportunity to create a hierarchy to organize class names for your application and systems.

Takeaways

Yes, Tailwind does take some of the hardest parts of CSS and simplify them. CSS specs are becoming easier and easier to use and we tend to praise these newer solutions like flex, grid, etc. We should praise frameworks like Tailwind the same.

Being a successful developer or engineer requires a willingness to try new things. Embrace change and new tools by trying them out for a period of time in applications or side projects and form opinions on the best use cases for different tools.

For me currently, I've been using Tailwind CSS whenever I spin up a new app. 😁 I do still use CSS and regular styles in my quick Codepen's and when Tailwind might not have a class out of the box for prototyping.

Tailwind has made me faster and more efficient by having less overhead to maintain and allows me to have an impact on applications faster in my day to day.