Embracing Improvements

Some of my coworker might remember that few years ago I was strongly against Tailwind CSS in one of our project.

The reason was that our design system wasn’t rigid enough for us to be able to use Tailwind, and that we ended writing new css class for each of our deviations.

The choice between,

<div class="my-element flex items-center bg-white"/>
.my-element {
  margin-left: 34px;
}
// or
.my-element {
  margin-left: 34px;
  @apply flex items-center bg-white;
}

and

<div class="my-element"/>
.my-element {
  margin-left: 34px;
  display: flex;
  align-items: center;
  background: white;
}

was obvious that if we ended up with a lot of deviation by creating our own class, let’s just stick with raw CSS.

We were using scoped CSS at that time, so we dont really care about name colission. If the choice was between the robust name of BEM and Tailwind, we’d probably go with Tailwind and just bear the pain of deviations.

Tailwind was still on its early days that time, it was slow to use, and there was no support for arbitrary values using square brackets. I kept pushing my team to stop using Tailwind, let’s stick with CSS as we don’t have a consistent design system.

But fast forward, Tailwind improved a lot. There was an improvements going on with Tailwind. JIT is a thing, compile speed was better, extending the configuration has become easier, and the support for arbitrary values allowed us to have an escape hatch without maintaining another CSS file.

So I decided to embrace Tailwind and starts advocating to use it for new projects. Even when the designer decided to nudge that margin into 171px, we’d have no problem as we can just m-[171px]

Where Tailwind Shine

Tailwind shines when we have a consistent design system and that the designer properly plan their design tokens and enforcing discipline. This way, developer can model their Tailwind configuration to match the design principles.

When thing goes south, deviating is just two keystrokes away (or 14 if you use m-[1234567890px]).

When there’s an improvements, we should embrace it. A lot of developers got too fixated by certain technologies that they missed good things happening at the other side of the fence.

However, it does not mean that we got the green pass to just use everything in our project. I experienced it first hand in an open source project where they implement all of the possible tooling without considering how it’d impact the performance and development flow. I stopped contributing when the package.json dependencies reached 60 or something — for a website that just show data from a database without any user inputs.

Remember, it’s always about the product, the team, and the workflow. It’s the technology that should adapt with those, not the other way around.

Building a one page landing page using React, Tailwind, Gatsby, SCSS, React Router, Redux, SQL in JS, and Web Assembly? Enjoy the 1 minute build time I guess?