DEV Community

A simple strategy for structuring TailwindCSS classnames

Nikolaus Rademacher on April 13, 2021

This is the third article of my small series about TailwindCSS. If you have not done so already, check out my other posts. Anyone who has proposed...
Collapse
 
maxart2501 profile image
Massimo Artizzu

How come every time I read an article about Tailwind it's about trying to solve its problems? And most of the times the solutions are pretty much what plain CSS can do just fine?

I was wondering... Why is this good:

const listItemClassNames =
  'mb-3 sm:ml-3 sm:mb-0 even:bg-gray-50 odd:bg-white'
Enter fullscreen mode Exit fullscreen mode

while this is not?

.list-item {
  margin-bottom: $size-3;
  &:nth-child(odd) {
    background: $gray-50;
  }
  &:nth-child(even) {
    background: white;
  }
  @media (max-width: $small-size) {
    margin-left: $size-3;
    margin-bottom: 0;
  }
}
Enter fullscreen mode Exit fullscreen mode

Just because it's more compact?

Collapse
 
wheelmaker24 profile image
Nikolaus Rademacher

The idea is to have a constrained system that only allows predefined values (the ones you have defined in the tailwind.config.js file). You are forced to design your components based on these "tokens". In a way you could achieve the same with SCSS / Sass mixins.

Another reason is that the compiled CSS file will stay small in size no matter how many components you have. With standard CSS approaches you would need to have specific style definitions for each component that will let the CSS output file grow in size.

Also when sticking to Tailwind you won't get in trouble with specificity issues (CSS overwrites and alike).

It's definitely a paradigm shift and can feel strange in the beginning. For me the constraints argument is the strongest, especially when using it in design systems.

Check out the official explanation of Tailwind's utility-first concept here:
tailwindcss.com/docs/utility-first

If you like, check out my other posts on Tailwind:

Collapse
 
maxart2501 profile image
Massimo Artizzu

I've already read the official documentation of Tailwind. And several posts already, including yours. Every single point that had been made has been debunked.

The fact that the final CSS file is smaller has meaningless advantages. Styles are still a very small payload and computational overhead for the web. A single picture could weigh more than all the stylesheets in an application, and if you're using React or similar the impact of JavaScript on the CPU is orders of magnitude bigger.

Moreover, using SCSS mixins may lead to code repetition, but compression algorithms are very good at deflating repeated text.

Specificity is a powerful feature of CSS. I've never understood why one should give up understanding and using it. If one has troubles with it, they could either learn how to deal with it or... learn Tailwind?

And again, if you still have specificity problems in an era of encapsulated styles, is pretty clear you're using the wrong approach.

I think I'll stick to good old SCSS for the foreseeable future. And advise against Tailwind and similar utility-first patterns, that in my view solve nothing but the need to develop a good methodology.

That you still need with Tailwind anyway, just like your posts have proven once again.

Thread Thread
 
wheelmaker24 profile image
Nikolaus Rademacher

I see your points here and I was pretty much coming from the same side. I'm not afraid of CSS / specificity and alike and was always sceptical when it came to CSS-in-JS solutions as they in my view solved problems that I never had (like the scoping issue). The cascade is one of the main features in CSS and you can benefit from it a lot when using it correctly.

Also I would never say that you have to use Tailwind for every project, but when working in bigger projects with many engineers especially it is important to have constraints – and I have not found a better solution for that yet than Tailwind: It's easy to learn not only for engineers but for designers as well as it helps you to think in constrained tokens. If you have a better solution for this, I'd happy to hear it from you!

It's also fun to look behind the code of Tailwind – it has clever solutions for many problems. With that it is at least a great library to learn from and apply in your own CSS code afterwards. The way Tailwind takes advantage of CSS' core features like CSS variables / the cascade / specificity is nice to see.

Collapse
 
andreidascalu profile image
Andrei Dascalu

It is, mostly because your organizational solutions go well with React/Angular. Do that in any other kind of web app, templating system and so on and it quickly gets out of hand. You need to manage your lists of classes in code and break the whole point of having a presentation layer.
Scss still works better. If there's a cross-apptype solution, I'd rather stick with that since it's usable in more cases.

Thread Thread
 
wheelmaker24 profile image
Nikolaus Rademacher

Fair point – these tipps will only help if you are using a framework / library that uses JavaScript / JSX for the "presentation layer".

Collapse
 
sarimarton profile image
Marton Sari

"Just because it's more compact?" Yes.

Collapse
 
moopet profile image
Ben Sinclair

I[f] you want to take it even further, you could outsource your styles to a separate file

Have you just invented... stylesheets?

Collapse
 
wheelmaker24 profile image
Nikolaus Rademacher

Hahaha, yupp... 😎

Collapse
 
tiagocsouto profile image
Tiago Souto

Isn't it an anti-pattern considering Tailwind's utility-first concept? If we're abstracting styles into JS objects, wouldn't it be the same as writing regular CSS classes and @apply'ing Tailwind? Even considering JS FW as React. I mean, the code looks more organized, but my understanding is it's still not what the official docs recommend.

Collapse
 
mohdahmad1 profile image
Mohd Ahmad
Collapse
 
wheelmaker24 profile image
Nikolaus Rademacher

Right, forgot about twin.macro. But with this you could also end up having cluttered components, wouldn't you?

Collapse
 
mohdahmad1 profile image
Mohd Ahmad

I use Framer Motion. Each of my elements look like

<motion.anyElementName />
Enter fullscreen mode Exit fullscreen mode

This is messy, with styled-components it become easier I can use

<appropriateComponentName />
Enter fullscreen mode Exit fullscreen mode
Collapse
 
shareef profile image
Mohammed Nadeem Shareef

I like to use componentName.module.css

  • We will have separate files
  • We can combine the CSS power with the tailwind
  • We will have a simple but powerful structure also.
Collapse
 
wheelmaker24 profile image
Nikolaus Rademacher • Edited

And within the CSS file you would @apply the Tailwind utility-classes? That's definitely a good approach. Although you will still end up with specific stylesheets for each component. Would be similar to SCSS with mixins IMO.

Collapse
 
shareef profile image
Mohammed Nadeem Shareef

yeah! it will be similar to SCSS and we can use the power of scss and tailwindcss combined, and yes I use @apply.

Thread Thread
 
nemethricsi profile image
Richard

But the slogan is that “you should never leave your markup”.

If I should create separate files for the styles I feel I did not reduced the mental work here :/

Collapse
 
juz501 profile image
Julian Chan

Is it just me or does this solution just look like SCSS again? Bringing with it the problems TailwindCSS is solving?

Collapse
 
ardiansyaherwin profile image
ardiansyaherwin

Hi, nice article and I really like this approach, actually I'm in implementing this into my project bu found a strange issue.

so the class is rendered, I confirmed it using inspect element, but the tailwind styles is not loaded.

is it maybe because of JIT mode?

Collapse
 
aalphaindia profile image
Pawan Pawar

keep sharing!!

Collapse
 
cemkaanguru profile image
cem kaan kosali

It is the most useful topic about tailwind. Unfortunately tailwind just a bad way of doing things.

Collapse
 
andrej_gajdos profile image
Andrej Gajdos

Does tailwind autocomplete work with this approach in VS Code?