[RFC] Airfoil: Coding an alternative to Tailwind
Tags: tailwindcss, frontend, css, libraries
Published: 2021-04-21 17:18:21

Update: Created a [crude github repo](https://github.com/brianboyko/Airfoil) for Airfoil. It's mostly just a placeholder right now. 

---

My [previous post on TailwindCSS](https://dev.to/brianboyko/tailwindcss-adds-complexity-does-nothing-3hpn) got a lot of views and comments. 

To my horror, while I've convinced many not to go down the path of Tailwind, a few others including, `(grumble, grumble)` _my team lead_, still think Tailwind has some good ideas. 

And here are some of his points: 

* Its valuable to be able to define a custom style within a single class, then use that wherever. For example: example box-shadow, border radius, different colors, font styles...
* Tailwind (with the CSS-in-JS tool, [twind](https://twind.dev/)) provides a mental model to organize utility classes without polluting the global stylesheet. 
* If you're going to use a utility class approach, why not use the same one as thousands of other developers? Otherwise you need to document your stuff well.  
* I think the alternative: building, managing, planning, documenting, fixing our own utility class solution is a nightmare.

And then he said some words I think he might now regret: 

> If you think you can do a better job I would love to see how you'd approach it. 

![WOO](https://media.giphy.com/media/yUI3a7RwLhOFy/giphy.gif)

# WOO! WEEKEND PROJECT

The truth is, yes, I *do* think I could do better. And I don't think it would take that long. 

To his points directly: I think that we can define a much smaller _subset_ of the features of Tailwind, and do it better. I think that the cost of "building, managing, planning, documenting, and fixing" our own library that is _tiny_ (relative to Tailwind) is going to be easier than maintaining Tailwind in our projects, (as I believe Tailwind doesn't remove code you have to maintain, it just obscures it.) 

Let's be clear - in this library, (working title: "Airfoil") I wouldn't want to do everything that Tailwind does, because I'm firmly convinced 97% of what Tailwind does, Tailwind doesn't need to do, and indeed, _shouldn't_ do.  

Instead, I'm talking about extracting only those utility classes which actually provide a good shorthand for complex concepts in CSS.  

So for example, I can see how someone might like the shorthand "container" for something like this: 

```css
/* breakpoints */
--breakpoint-sm: 640px;
--breakpoint-md: 768px;
--breakpoint-lg: 1024px;
--breakpoint-xl: 1280px;
--breakpoint-2xl: 1536px;
.container {
  width: 100%;
}
@media screen and (min-width: var(--breakpoint-sm) {
  .container {
    max-width: var(--breakpoint-sm);
  }
}
@media screen and (min-width: var(--breakpoint-md) {
  .container {
    max-width: var(--breakpoint-md);
  }
}
@media screen and (min-width: var(--breakpoint-lg) {
  .container {
    max-width: var(--breakpoint-lg);
  }
}
@media screen and (min-width: var(--breakpoint-xl) {
  .container {
    max-width: var(--breakpoint-xl);
  }
}
@media screen and (min-width: var(--breakpoint-2xl) {
  .container {
    max-width: var(--breakpoint-2xl);
  }
}

```

**This**, to me, is the _perfect_ example of when a utility class makes sense to use. One word: "container" replaces 30 or so lines of code. It's reusable and does what it says on the tin. The only thing I'd do differently is name it 'with-container' rather than 'container', as I think the prefix 'with-' makes a lot of sense for a utility class to distinguish it from a semantic class. 

And if Tailwind were full of code like this, I wouldn't have a problem with it. 

But "container" is one of the eight or so exceptions which prove the 200+ rules that Tailwind is just full of stuff that can be replaced by one or two lines of CSS. 

```css
.flex {
  display: flex;
}
.py-6 {
  padding-left: 1.5rem;
  padding-right: 1.5rem;
}
```

So I went through Tailwind's documentation, and picked out the nine classes that I'd actually _keep_ out of the 200+ that Tailwind offers. 

And they are: 

* container
* ring
* box-shadow
* filter (but possibly as a function/mixin)
* backdrop-filter (which will be difficult as neither Edge nor Firefox support backdrop-filter natively)
* drop-shadow
* animate-spin
* animate-ping
* animate-pulse
* screen-reader-only

And at this point, if you're saying to the screen: "Well, what about X?" -- that's why I'm writing the post. 

I'm soliciting comments on what you think needs to be added to such a library.  Maybe it's in Tailwind and I missed it.  Maybe it's not in Tailwind, but you wish something like it was.  

I also would like to know how you think it should be developed.  I think right now, the goal is to start life as a .CSS file on Github Gist, to get the proper effects right. 

Then, provide two different versions - one as styles and mixins as a partial (_airfoil.scss?) for an SCSS file, another which takes a function and just returns a string, for integration into libraries such as [styled-components](https://styled-components.com/) and [emotion/css](https://emotion.sh/docs/introduction).  

But again - before I do that, I need to scope out the project.  So - please retweet this among your dev friends, both ["pro-tailwind" and "anti-tailwind"](https://pbfcomics.com/comics/skub/) and talk about what you'd like to see - or not like to see - in the comments below.