Tailwind bills itself as “a utility-first framework packed with classes … that can be composed to build any design, directly in your markup.” Great, but what does that mean? It means Tailwind is not another UI kit like Bootstrap or Material UI, and that means your Tailwind site won’t look like every other Tailwind site… looking at you, Bootstrap. Instead of being component oriented, Tailwind uses atomic CSS to create a design language that can be used to achieve any project’s design goals.
Life Before Tailwind
Before ETR decided to adopt Tailwind into our toolbox, we faced all the usual issues that come along with the use of CSS, especially as projects grow and change over time. BEM naming helped to alleviate some of the issues, but BEM itself can be quite cumbersome. Scoping styles to specific components works, but it leads to stylesheets becoming bloated with repeated declarations. The global nature of CSS means that even projects that start off with a plan can suffer from confusing overrides, specificity issues, and unexpected naming issues. Each additional component increases the size of the stylesheet. Then add media queries to the mix and, before you know it, there are tens of thousands of lines of CSS spread across dozens of files. Updating a style becomes a daunting task because there isn’t a way to be certain that the update won’t have unintended effects in an unrelated part of the project.
The Benefits of Tailwind
The atomic nature of Tailwind’s classes means that for the most part one Tailwind class sets one CSS property. At first, this aspect of Tailwind can be counterintuitive. What’s the big deal? But Tailwind isn’t just a random collection of utility classes. It is a highly configurable tool that creates a design language consisting of a finite and knowable number of classes with predictable naming conventions and a shared spacing scale.
But wait, there’s more!
Tailwind doesn’t stop there. Its design language also includes modifiers for specifying the conditions under which a class’s style is applied, and there are a plethora of modifiers covering things like pseudo-classes, pseudo-elements, interaction states, form states, parent states, sibling states, responsive breakpoints, media queries, viewport orientation, data attributes, aria attributes and states, and even custom defined and arbitrary value modifiers. Modifiers can even be stacked together to create incredibly specific layouts and interactions based on a project’s needs. Need to target an ::after pseudo-element in a browser running dark mode on a page between 768px and 1024px where the element’s parent element is focused, Tailwind has you covered – dark:md:group-focus:after:text-white.
Tailwind’s design language is flexible enough that 99% of the time, there is no need to write any CSS at all, removing the need to come up with endless classnames, BEM or otherwise. Just apply the classes you need, when you need them, where you need them, directly in the HTML, reducing context switching and saving time. Even if the time saved is only a second or two, when it happens thousands of times over the life of a project, the savings add up.
Styling components with Tailwind classes helps decouple them from the stylesheet, making them more portable. When similar components are present in two different projects, moving the component from one project to the other becomes a matter of copy-paste and tweak. This portability has been key in ETR’s development of our internal component library. More time saved.
The atomic nature of Tailwind’s utility classes means no more worrying about changing styles unintentionally. The styles change when the class name changes with no unpredictable side effects and no bugs to hunt down. Time saved again.
Bridging the Designer/Developer Gap
At ETR the use of Tailwind starts in the design phase of a project. Because our design team is able to work with Tailwind from day one, it helps to bridge the gap between the design and development teams. The job of translating a project’s design language into CSS is handled by Tailwind, and everyone speaks that language from the start. When elements of the design fall outside of Tailwind’s base configuration our designers are able to call out those elements. For example, if the font sizes differ from the default Tailwind font sizes in a design, our designers will provide the development team a map of how Tailwind’s text sizes should be configured. This ultimately saves development time and the need for developers to hunt through a design file for all of the different font sizes in use.
Beyond just being a shared design language, Tailwind has allowed our designers to design in browser when the opportunity presents itself, and even complete entire front-end builds without the need for help from the development team. This eliminates the need for ramp up should the development team need to take over the build given the CSS approach is exactly how the development team would have done it using Tailwind.
Tools for Tailwind
While Tailwind is awesome on its own, there are some additional tools that help make using Tailwind even better.
As Tailwind has matured and adoption has increased, a healthy ecosystem has sprung up around it. UI kits built on top of Tailwind include Tailwind UI, Flowbite and daisyUI to name a few. There are official plugins for typography, forms and line-clamp, as well as unofficial plugins for spinners and debugging amongst many others.
Tailwind provides an official plugin for VS Code called Tailwind CSS intelliSense that provides autocomplete, syntax highlighting and linting. So if you’re using VS Code as your editor, and let’s be honest, most of us are, this is a must have plugin.
Another great tool for developing with Tailwind is the Tailwind Config Viewer, written by ETR’s very own Ryan Ogden (and I’m not just saying that because he’s my boss). Tailwind Config Viewer spins up a local web server that provides a visual representation of the current tailwind config complete with a dark mode option and click-to-copy class names.
Depending on your setup, you may also find the PostCSS Language Support plugin for VS Code to be helpful. Although it isn’t necessarily Tailwind specific and you’ve basically been promised Tailwind means you’ll never have to write CSS again, the PostCSS Language Support plugin provides support for things like nested styles, custom selectors and SCSS style variables, as well as syntax highlighting, for the rare occasion when you do need to write vanilla CSS.
Adopting Tailwind
The single biggest downside of Tailwind adoption is the learning curve. Developers and designers spend years honing CSS/Less/Sass skills, and Tailwind comes along and basically throws all that out the window. From our experience, any time spent on learning Tailwind is quickly saved by an improved and streamlined workflow.
While some of our development team was hesitant to adopt Tailwind at first, everyone was encouraged to keep an open mind and to give it a try on a small project or prototype. After a few weeks, the entire development team had agreed to use Tailwind, and we were well on the path to writing the most maintainable and scalable CSS we had written in years.
If you are looking to get started with Tailwind today, head on over to their great documentation, or tinker in their interactive playground, then come back and let ETR know if we can help get your next Tailwind-powered project off the ground.
Contributors
