5th of August, 2022 · In Technical · Tagged with css, web

CSS Libraries are Bloat

CSS libraries like Tailwind, and OpenProps have become immensely popular in recent years. The proposed benefits from their proponents are that you can get up-and-running very quickly and that you don’t have to deal so much with naming classes etc. Here I will argue that in most cases while there may be some benefit to doing CSS with a library this way the drawbacks far outweight the benefits.

Tailwindcss’s approach, many utility classes + purge unused css

Tailwindcss’s approach is to give the developer a large number of utility classes like text-sm, bg-blue-300 etc. and then remove all the unused classes from the library at the end. The benefits of this approach is that you don’t need to worry about html class names matching styles in the stylesheet. For Javascript component libraries you then let the library handle componentization instead of using a css naming convention like BEM (Block Element Modifier).

I have used Tailwind extensively on a number of small projects and my takeaways of the cons are:

  1. You often have to mess with the tailwind.config.js file to extend the library anyways
  2. For certain complex animations etc. you just need to write raw CSS anyways
  3. It really makes the HTML harder to read. This is because the class names in HTML go horizontally across the document instead of vertically like in a CSS file. Editing / reading vertical text is much easier
  4. You need a system like PostCSS for purging unused styles. That is not always fast, and depends on Javascript when sometimes you don’t want to (eg. a static site generator like Hugo or Zola)

The reason I was using Tailwind in a bunch of these small projects (including this site at one point) was that it was extremely fast to get up and going because especially of the built-in color palette. However, the more I used it the more I became frustrated with both how non-simple it was and how often I needed to eject out of using it in the first place.

OpenProps: Tailwind but using CSS variables

A significant step in the right direction was OpenProps which rather than mess with the way that you write CSS or HTML just gives you a plethora of CSS variables to get started with. This has a nice effect similar to getting started with a project with Tailwind, in that you don’t have to fuss with creating your own color palette or spacing system.

However, OpenProps is not without some issues as well:

  1. You still need a system for purging the unused props (or only using a certain amount of them)
  2. the “normalize” is overly aggressive / opinionated

The bigger issue with open-props isn’t so much of an issue, but that it really is just easier to copypaste the props that you need into a raw css file and go from there. Maybe it could / should evolve into just a resource for easily copy-pastable css variables, but not encouraging using it as a library?

Moving to SASS/SCSS

The last step in my evolution back to CSS simplicity was to use the SASS css compiler. This compiler let’s you write slightly fancy syntax for CSS which is especially useful due to it’s implementation of nested selectors. Another good thing is that it’s pretty straightforward to compile a .scss document down to a .css one (although I sort of wish the compliler was rewritten in a faster language).

There are a number of other features of SASS like mixins / loops / etc. which can be useful in large projects, but for simple ones I mostly just rely on nesting.

Conclusions

If you are using Tailwindcss don’t feel bad. I was very drawn to it’s ability to create good looking websites quickly without having to fuss with raw CSS. But the more and more you use it the more you will feel that something isn’t quite right. I would urge anyone who is on the fence to basically just focus on learning actual CSS rather than any library or framework. Having good CSS skills will be fundamental regardless of which library you choose (Tailwind tries to abstract this away to an almost different language, but due to somewhat commmon edge cases fails to be a total abstraction).

I can totally recommend just throwing a few variables on the :root element and getting started with a raw .css file (or SCSS) you almost certainly won’t regret learning it that way (which is the way you were always supposed to depsite what the hype-machine would have you believe).

Future: Just CSS?

It seems like CSS is getting ready to add nesting. When this is widely supported by browsers, I imagine that I will transition back to just writing simple CSS documents and will have come full circle.