TailwindCSS can often be a hot topic in the web development community. Some developers love and embrace it, while others reject and repulse it. Whether you like it or not, I think it’s time to accept that it is here to stay.

I stumbled upon TailwindCSS a few years back while doing some frontend work for an agency. Back then there were two ways you could use TailwindCSS. You could install every possible style combination and end up with a bundle that is almost 2MB uncompressed. (That’s a lot of code, especially for a CSS library) Alternatively, more complex, yet recommended for production, you could setup TailwindCSS as a PostCSS plugin that would produce a very targeted CSS bundle that only contained the class names you used in your code.

<div class="border-2 p-4">
  <h2 class="text-xl">Tailwind Makes Styling Easy</h2>
  <p class="text-md">Applying styles never was easier.</p>
</div>

You can probably assume which approach the previous site developers took. Needless to say, but my first introduction to TailwindCSS wasn’t pretty. I was both greeted with this new utility-first approach that was completely foreign to me and also staring down the barrel of a huge file of single attribute classes of CSS, with CSS variables which I barely grasped at the time, all over the place. I quickly felt overwhelmed and out of my depth.

I dove head first into TailwindCSS documentation to learn more about the product. When I first started using TailwindCSS, the composability of it was what really stood out to me. I was able to rapidly pick up the class-name conventions and before I knew it I was doing basic styling without referencing the docs. Despite that, TailwindCSS felt bulky to use, there was a lot of little levers/switches, and overall I disagreed with some of the design opinions. Thankfully back then TailwindCSS was extendable and easy to configure. Despite it’s flaws, it was a breeze to extend and felt powerful enough that it made CSS enjoyable.

Critics often argue that TailwindCSS’s paradigms directly undermine the core-principals of separation of concerns. Introducing overtly verbose styling into the HTML markup that can easily become eye-straining and difficult to deal with. Some make the case that adding common styling to the markup and over reliance on a framework leads to less unique website design and creates a homogeneous experience across the greater web. Many developers remember the bootstrap era of web-development. Every website had the same copy paste bootstrap components and theme and it felt like the internet lost it’s creativity.

However, to understand why TailwindCSS is widely adopted today, we need to understand the reasons why it was built. Adam Wathan, the creator of TailwindCSS, wrote that Nicolas Gallagher’s blog post About HTML semantics and front-end architecture had him “fully convinced that optimizing for reusable CSS was going to be the right choice for the sorts of projects I work on.”. In Nicolas’s post, he goes on to buck that idea that HTML specification section on classes is wrong. HTML5 specification states that class names should describe the nature of the content, and not the styling that is applied.

Nicolas goes on to claim that class names inherently have little value to the structure of content and better serve a purpose to describe how content is represented. They also state that class names should be both functional in nature and also provide useful context to the developers that work with them. Adam, using this philosophy as inspiration, began writing CSS with a focus of not using content driven naming conventions and instead focus on building composable and re-usable classes. Adam stated that in an effort to give everything re-usable class names he found that “The more a component does, or the more specific a component is, the harder it is to reuse.”

With those learnings in mind, and through trial and error Adam went on to create the composable design library that we know as TailwindCSS today. With a utility-first approach TailwindCSS enables developer to rapidly prototype and compose unform and consistent component styles. TailwindCSS is slightly-opinionated but provides guardrails with grace and good reason.

These days with improvements to the JIT compiler that now powers TailwindCSS, you can easily break out of these pre-determined defaults by doing crazy inline-classes like width-[10rem] which compiles and just works. I don’t recommend deviating from the defaults because then you start leading your self down some of the same pit-falls that TailwindCSS was designed to solve. Standardizing at the utility level comes with a lot of benefits. UI’s tend to work better and become easier to consume with consistent spacing and design.

<div class="border-[1px] p-[4px]">
  <h2 class="text-[20px]">Tailwind Makes Styling Easy</h2>
  <p class="text-[16px] text-[#3aff9e]">
    But overriding preset classes can be a foot gun.
  </p>
</div>

TailwindCSS also comes out swinging big for responsive design. By providing a utility first composable approach to web design, you can easily create different experiences for different viewports. Combining breakpoints and utility classes such as flexbox or grid, can enable some really clever simple-yet elegant designs.

These days there are tools such as cva, clsx, and twMerge that can help you wrangle your class names. You also have libraries out there such as Radix UI and Shadcn/UI that really push the envelope to deliver high-quality accessible and customizable components that just work. Today it is easier than ever to embrace TailwindCSS, and I think if you are not using it, you are doing yourself a disservice.

-Alex