Adopting Tailwind CSS

14 Apr 2020

It’s now more than seven years since I converted this site to use Twitter Bootstrap. At the time, I was pleased to be able to use Twitter Bootstrap to enable the site to be responsive to different devices.

However, time moves on. Almost two years ago I tweeted:

And this was the reply that interested me most:

More recently, at this year’s RubyConf AU opening party, my friend Josh Price was extolling the virtues of Tailwind CSS. So, when the recent four day holiday break presented itself, I took the plunge and converted this site.

The Process

There are plenty of good resources on the web about Tailwind CSS and supporting technologies so I don’t intend to provide a step by step guide here. However, I will reflect on the steps I ended up taking.

Remove Twitter Bootstrap

Naturally, having created a git branch on which to start experimenting with Tailwind CSS, the first step was to remove Twitter bootstrap. For me, that essentially entailed deleting the twitter-bootstrap-rails gem from my Gemfile as well as any references to it in my Rails application. As expected, that resulted in the pages on my site being displayed bereft of any styles.

Install Tailwind CSS

To install Tailwind CSS, I used this guide as a reference as well as the official advice.

So far so good. Now it was time to start making use of this “highly customizable, low-level CSS framework”.

Build up Tailwind CSS Styles

The next phase was one of experimentation. In some cases, such as for my Rails layouts, it involved applying Tailwind styles directly to <div> tags. This was the first time I started to realise that Tailwind adopts a mobile-first approach. For example, consider the following:

	<div class="block lg:hidden">
	<!-- other tags -->
	</div>

The significance of lg:hidden is that this tag will be hidden for devices of size lg and above where lg equates to max-width: 1024px. For more on Tailwind’s approach to responsive design, see the official documentation.

As I learnt more about Tailwind’s styles it became clearer to me that I needed to focus on the app/javascript/src/application.css file. In addition to incorporating Tailwind’s base, components and utilities styles, this is where I built up a list of styles to apply to various tags and classes. As a simple example, my first custom definition in this file is:

	p {  
		@apply font-serif py-2 leading-snug;  
	}

Translated, this means that for paragraphs, I apply Tailwind’s font-serif, py-2 and leading-snug styles. What do each of these mean? To find out, explore the documentation about font families, padding and line height. The documentation is very helpful.

Tailwind styles can also be applied to classes, as in the following example.

	.error {  
		@apply text-red-700 pb-2;  
	}

I’ll leave you to explore the documentation this time to figure out the meaning of the styles.

Use Custom Tailwind CSS Forms

Whilst I got most of the way towards styling my site using just Tailwind’s styles, I did find difficulties with forms. To solve this problem I used the Tailwind CSS Custom Forms plugin. I was then able to apply styles from that plugin as follows:

	form input {  
		@apply form-input mt-1 block w-full;  
	}

Complete transfer from Asset Pipeline to Webpacker

This site has been around for a while. I recall creating it in 2007. I can’t be exactly sure when because the git history only goes back to 26 April, 2009 when I migrated it from Subversion to Git.

Anyway, as a developer who leans towards the server-side, I’ve neglected some aspects of upgrading the site along the way. One of those has been moving from the Rails Asset Pipeline to Webpacker. That is no longer the case. As part of converting the site to use Tailwind CSS I realised that I needed to completely move my assets to Webpacker. The penny dropped when I understood the reason why the CodeRay styles that I use for code syntax highlighting were no longer working. After all, the following code snippet in my layout has a clue:

	<%= stylesheet_pack_tag “application” %>

The word “pack”, of course, indicates that the styles are managed by Webpacker.

Thankfully, the app/assets directory no longer exists in my application.

The Verdict

I now understand why Sebastian and Josh gave Tailwind CSS such enthusiastic endorsements.

Once I had experimented enough with applying the styles to tags and classes in a way that the styles could be reused, I found the experience addictive. And that’s saying something for a predominantly server-side programmer who cut his teeth on mainframes several decades ago.