TailwindCSS
First impression of Tailwind.css
Last week I rebuilt a personal project with Tailwind.css, a CSS framework that uses utility classes to compose interface styles. Having used it for a week on a handful of areas, here are my first impressions.
Pros
This is the most important pro, and outweighs all cons listed below: using Tailwind lets me style the frontend of my website as fast as I can think it. It's really that simple. If I can visualize a layout, I can basically create and style that layout at roughly the same rate as my brain. This is a superpower. Compare this to some of my previous workflows, where every element needed to be extracted out into a `styled-component` and I had to constantly juggle files, imports, and exports. It's night and day, and I'm really excited by this.
Things are mostly intuitive. Once you start learning the Tailwind vocabulary, you can start to predict how a given utility class will be named without ever having looked it up in the docs. There are a few notable exceptions - see my cons below - but for the most part it's really easy to guess your way towards correctness.
The defaults are pretty good. Sensible defaults can make or break a framework like this, and I suspect that Tailwind's base configuration for color, type, and spacing will get most people to a mostly good website. The best example of this is the typography plugin which gives you access to a `prose` class. This class makes all of its children elements look...pretty good! If you are just trying to style a blog post or block of long-form content with some basic paragraphs, lists, and block quotes, this single utility class will save you so much time. I use it everywhere, and have only needed to eject a few times in my configuration file to make things fit in better on my site.
Pros
I'm 99% sure I'm doing something wrong, but whenever I update my root `tailwind.css` file, it takes forever to recompile my Next.js project. Sometimes 10-15 seconds (where a normal file change should hot reload my page in less than a second). I've tinkered with compilation settings, like avoiding CSS purging in `development` mode, but that broke production deploys. Clearly I'm doing something wrong, but the fact that it's not "built in" to the Tailwind ecosystem to optimize for local development feels wrong. I would love to see a stronger enforcement of great conventions built into the entire framework so that people don't have to even bother reading docs for "how do I purge unused styles?" – this should be the default behavior, with intelligent changes based on the environment.
I've been writing CSS for years and years, so when Tailwind breaks my vocabulary I'm forced to stop, think, refer to the docs, and relearn a new way of working. For example, in CSS you can set the `visibility` property to `hidden` or `visible`. In Tailwind, the utility classes for `visibility` are `visible` and `invisible`, which is really odd. Simultaneously, if you want to `display:none` an element, Tailwind has the utility class `hidden`. Confused? Me too. These are backwards: `hidden` and `visible` should control `visibility`, and there should be a discrete
`display-none` utility. There are a handful of examples like this that make you stop and think,
and each time it's breaking years of learned vocabulary.
Tailwind CSS is very good, and I'm already happy that I took the time to learn it. This being said: I'm still bad at Tailwind. There is a learning curve, a new vocabulary, a new way to think about abstractions and overrides and customization, and I can tell that I've barely scratched the surface of what's possible. And that's a good thing: there's a lot left to learn.