Experience with using Tailwind in Phoenix LiveView

Tailwind seems to cause polarising reactions: some people love it and others don’t want a bar of it. So I thought it would be good to write about my experience with using it.

A couple of years ago I was busy introducing Elixir/Phoenix/LiveView to a company where I worked. It was a new stack for us, selected to implement a new product. As part of the process, I had to figure out the best way to work with CSS.

Tailwind was recommended as the default option for Phoenix. However, I was initially sceptical of Tailwind. I just couldn’t understand the value proposition of having a shorthand that basically corresponds one-to-one with individual CSS properties.

Nevertheless, one consideration eventually convinced me to go with Tailwind, and that was the fact that Tailwind-supplied shorthand provides a constrained design language for the team, thus helping maintain UI consistency across the whole base. The main thing that Tailwind allowed us to avoid was the application of inconsistent, arbitrary values in different places: things like people slapping padding-top: <whatever>px with different values of <whatever> on different parts of the UI.

We were also able to generate our Tailwind theme from a set of parameters specified by a company-wide design system, helping ensure consistency at a higher level (across products) as well.

A couple more advantages became apparent later, as we built out the product and used Tailwind extensively:

  • Somehow, with practice, the combination of Tailwind docs (which are very good) and the shorthand becomes much easier to work with than plain CSS. As much as I tried, CSS never became intuitive to me and I had to keep looking up even the basic stuff. With Tailwind, writing things like mb-4 or flex items-center or whatever became second nature. Other people on the team reported a similar experience.
  • Co-locating styles with HEEX (or even JSX if we think about React) makes a lot of sense: it’s easy to work with, and means components are fully self-contained. The fact that Tailwind shorthand is shorter than CSS properties makes it easier to work with styles, whether it comes to writing them, reading them, or reviewing PRs.

All the advantages I listed are laid out on the Tailwind home page as well, and the motivation is similarly explained in the post that introduced Tailwind.

As a result of my experience using Tailwind for a product built by a team over a couple of years, I became a convert and will now reach for it for any new project. Recently I tried it out with React and Rails and it worked just as sensibly as with LiveView.