in Uncategorized

First impressions from using Tailwind CSS

I have been writing web templates using HTML and CSS for over 10 years. I am no expert or at least I stopped being one with the rapid development of CSS 3 and all the nice things modern browsers support nowadays. I have also never been a strictly frontend developer, so I don’t follow the CSS development that closely.

In the past I typically wrote CSS by creating custom classes, either trying to create a set of classes for components using semantic names or defining a utility class here and there.

BEM and other approaches

At my previous job we tried adopting BEM as the naming convention and consequently I used it for my own stuff as well. In larger codebases, CSS has always became unmaintainable, partially due to its nature and partially because people I have worked with were never true frontend developers who would invest the time to make strict rules and follow them. In that context, BEM didn’t really help that much with maintainability. I was also frequently struggling to structure the HTML and name the relevant CSS classes properly. I am not saying that BEM is a bad way to structure CSS, just that creating maintainable CSS with it is still hard and requires experience.

One of the more lightweight alternatives to BEM is SMACSS. It definitely looks promising because of its simplicity, however I have never came around to actually put it anywhere.

And of course we can use frameworks like Bootstrap or Bulma to help us with the basic layout and elements, but eventually we will need to write our own CSS anyway and so it hardly solves the problem for highly-customized websites.

Tailwind CSS

Recently I have seen a lot of discussions about atomic or utility-first CSS. If you want to read about the general advantages of it there is a nice collection of articles named The Case for Atomic / Utility-first CSS. Of course, this approach has its own problems, starting with possibly ugly and bloated HTML, bloated CSS without optimization, new ways to think about creating reusable components and so on. I know I was skeptical at first. Anyways, given all the bad experiences with organizing CSS, I wanted to give it a try.

To do that, I chose Tailwind CSS, one of the utility-first frameworks that is all the rage now. I used it first on a micro page efficientdeveloper.com and then experimented with it a bit more in other projects.

First thing to note here is that even though there is a CDN version of Tailwind available, to use all the Tailwind benefits we will typically want to install it via npm and build it locally, in same cases using other tools like PostCSS or Webpack. There is a sufficient official documentation for it, but I think it is worth mentioning for people who are not familiar with or don’t want to use various JavaScript tools.

Once the setup is finished, building/prototyping new layouts and elements is really easy, fast and productive. There are plenty of examples on the official website and even a screencast from the authors. It definitely takes a moment to learn some basic naming conventions of the utility classes but there are typically very easy to remember if you know CSS since they are derived from the CSS properties. In the beginning I recommend to search for “Tailwind cheat sheet” online and pick something you like – there are plenty of them and they are a big help.

This is how Tailwind looks like on efficientdeveloper.com:

I am definitely at the beginning of my Tailwind/atomic CSS journey, but I can already see one big benefit for me: I don’t have to think about naming classes most of the time which really reduces the cognitive load when creating a new layout or a component, especially so compared to BEM. I am also not really writing any CSS, just writing my HTML markup. It is quite pleasant not to go back and forth between markup and styles. On top of that there is a great VSCode extension Tailwind CSS IntelliSense which makes writing markup really fast.

I haven’t played with extracting components yet, so for now all I do is just using utility classes and making a copy of the code for the same “components”. For large projects this is probably not the best way, but for smaller projects this feels great and allows us to customize each instance easily. This is also not an issue if we are using a frontend framework like Vue.js or React, because then we can just use Vue or React components.

Now, I am definitely sold on the prototyping side of things, but what about maintenance? I think editing becomes easier with Tailwind, because we don’t have to go look for all the places where a specific class is defined and overwritten (even though browsers make this pretty easy) and we will typically not break anything in another place, because we are just adding or removing atomic classes for specific HTML elements. Also, no more mess in the CSS, as the number of custom classes is reduced to a minimum. How this changes once we want to extract Tailwind components I am not sure.

Overall it seems like Tailwind CSS is a solid choice for building web interfaces, especially interfaces which will use a lot of custom elements, because creating new elements is so easy. I definitely recommend to check it out, even if you are skeptical of utility-first CSS concept.

Loading Likes...

Check out my upcoming book Efficient developer on software development.