DEV Community: maiconsanson

Using Tailwind for four months

maiconsanson — Fri, 01 Mar 2024 14:26:32 +0000

This post was written in October 2023; some data provided here may have been changed.

Personal projects are great; you can choose the entire application stack: database, environments, deployment, testing, back end, front end, how to organize tasks, and more. In these projects, you can achieve a level of learning in a company that you would hardly have. So, take advantage, 'play' startup in your free time, and bear the consequences of your decisions.

My focus is on the front end, but I dabble in the back end a bit because it's a great feeling to be able to, on my own, bring a crazy idea to life and put it into practice.

I'm a bit of an old-timer (+40) and was already working in development before the advent of JQuery and Prototype. I never went to college for this field, but I graduated from a public university in Music and Fine Arts... go figure.

Anyway, I want to say that I've seen a lot out there. Concepts and ideas that come and go, old problems with new names, and old solutions with a new look.

But I have to focus, and I am here to talk about styles in a web application.

In recent years, working as a senior developer in companies of various sizes, I have increasingly distanced myself from CSS, which, modesty aside, I know very well and have always found fun and therapeutic. I've never complained about it, but it's common to use a pre-designed Design System, and you just 'program' the blocks (sometimes applying Atomic Design, which would already lead to another article when it makes sense) without worrying too much about the style of the components.

It is common for a project out there to use a CSS-in-JS solution like Styled Components, Emotion, Stitches, Linaria, and others when adjustments are needed. They are great; I've used them for a long time and love using them when it makes sense.

Once, I used Sass with CSS Modules to style a practical front-end test for a position at a medium-sized company. During the interview, one of the 'senior developers' asked me:

Why use Sass? It's somewhat uncommon these days. Why didn't you choose CSS-in-JS? Don't you think it's a bad practice to go back to using CSS or Sass?

I just smiled. However, over time, I've seen more and more front-end developers who knew very little about CSS, Modules, Custom Properties, the power of the cascade effect, and its countless possibilities. Professionals who enter the market only use JS/TS as the default for writing styles and see CSS as outdated. What a crazy situation!

Returning to my case, in this fresh new project, I decided to use Server Components along with NextJs and give a chance to the much-discussed TailWind Css. It's a relatively complex project with a strong focus on the user experience, featuring a simple interface but with details of unique interactions and multiple themes.

With that said, here are my conclusions after four months of daily use.

What is Tailwind CSS?

For those who landed here by chance, in summary, Tailwind CSS is a CSS framework similar to the old Bootstrap.

The main difference is that each class in Tailwind corresponds to a CSS property (or pseudo-class/element) but with a slightly different name. The so-called Utility-first.

For example:

The class z-0 translates to the property z-index: 0;.
The class overflow-hidden translates to the property overflow: hidden;.
The class hover:underline translates to the pseudo-class :hover { text-decoration: underline; }.

Controversial Aesthetics

In the examples we come across, including in the documentation itself, we find this type of markup structure:

<div class="w-9 h-9 rounded-lg flex items-center justify-center text-slate-700 peer-checked:font-semibold peer-checked:bg-slate-900 peer-checked:text-white">

I care a lot about the functional aesthetics of code (beauty + readability), clean code with good sense, and organization.

When reading the above code, it bothers me. I find it difficult to understand what is happening, and I lose focus with all these classes cluttering my markup.

Markup and style should be isolated as much as possible, in my opinion. I don't need to know that an element has a flex position if I don't want to know that at the time.

My thought was:

Alright, these are just examples, and I can work around it.

I'll create a function to handle this.

And I resolved it this way:

For each component that contained styled elements, I created a styles.js.

import { cleanClasses } from '@helpers'

export default function classNames({ hasSomeProp }) {
  return {
    content: cleanClasses(`
      ${hasSomeProp ? 'border-green' : 'border-black'}
      border
      flex
      h-9
      items-center
      justify-center
      peer-checked:bg-slate-900
      peer-checked:font-semibold
      peer-checked:text-white
      rounded-lg
      text-slate-700
      w-9
    `),
  }
}

Note: I always sort my properties in alphabetical order.

And inside my component, I imported that file and applied it to the element.

import classNames from './styles'

export default function MyComponent({ children, hasSomeProp }) {
  const c = classNames({ hasSomeProp } )
  return <div className={c.content}>{children}</div>
}

Solved, I thought!
I isolate all the classes and keep my components clean! 🤘

But notice that in styles.js, there's a function called cleanClasses(). I had to create it because the indentation using template literals was messing up the final minification of the HTML.

To solve and keep my indentation the way I think makes sense, I created a function to remove unnecessary characters that could interfere with minification in the final build.

import { isString } from '@helpers'

export default function cleanClasses(value) {
  if (!isString(value)) return ''

  const removeFalsyValues = value.replace(
    /\b(?:undefined|null|false|NaN|'')\b/g,
    '',
  )
  const removeExtraSpaces = removeFalsyValues.replace(/\s+/g, ' ')
  const cleanedClasses = removeExtraSpaces.trim()

  return cleanedClasses
}

I liked the solution, and it served me well, but I started to have a nagging feeling...

I enjoy programming, but I'm lazy; the less I have to code, the more I like coding. 😂

Unnecessary Abstractions

The Tailwind documentation became a part of my daily work routine.
To ensure that a particular class represented the property I wanted, There was always a tab open for me to refer to.

And it's normal; I have to learn the framework. But this reliance on memorizing classes that are essentially property names (that I already knew by heart in CSS) started to irritate me, and I found the abstractions unnecessary.

In a way, I dare say, I was 'unlearning' the properties of plain CSS.

I used this term on purpose because after a few months using TW, and having already migrated the project to CSS Modules, I found myself adding Tailwind classes instead of CSS properties. As they are similar names, my brain ended up substituting these values.

For example, do you know which property the Tailwind class justify-center corresponds to?

🔘 justify-content: center;
🔘 justify-items: center;
🔘 justify-self: center;
🔘 justify-tracks: center;

Hint: justify-tracks is still experimental and doesn't even exist in Tailwind.

You'll have to go to the documentation If you're in doubt. 🤡

Handling more complex selectors

One aspect I didn't find productive was using more complex selectors. While styling a single element is okay, things get awkward when you need something more complex that involves other elements.

For example, let's say that I don't have access to an items list, but I need to modify them.
Note: This is far from complex.

<ul className={styles.ul}>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

With Tailwind, I would have to add something like:

import { cleanClasses } from '@helpers'

export default function classNames() {
  return {
    ul: cleanClasses(`
      [&_li]:rounded-full
      [&_li]:border
      [&_li]:border-black
      [&_li]:bg-white
      [&_li]:px-2
      [&_li]:py-0.5
    `),
  }
}

It is very wordy to say that each property is an item in the list with [&_li] and have to inform that repeatedly in each TW class. Not to mention that I can't use shorthand properties. There's a plugin, but I don't want to clutter my application with packages.

With CSS I just declare it like:

.ul li {
  background: var(--color__white);
  border-radius: var(--radius__full);
  border: 1px solid var(--color__black);
  padding: var(--size__0-5) var(--size__2);
}

And I won't even go into detail about sibling selectors](https://tailwindcss.com/docs/hover-focus-and-other-states#styling-based-on-sibling-state) and other selectors that are trivial with native CSS. I feel like I'm reinventing the wheel, but this wheel isn't very round.

Themes

Another thing I didn't like was the way of adding multiple themes and their various design tokens using TW. I thought it would handle that natively, but it doesn't.

One option is to install an additional dependency like tw-colors, as we don't have that natively in the framework (we can only change the tokens of the current theme). It's nice and works well.

Another option is to use native CSS variables and inform Tailwind how to use them. But wait, I don't want that since I chose the framework to handle the styles. I only want to use Tailwind and its gang.

Where is the cascade effect?

Quickly, I learned that TW removes one of the most important aspects of CSS (which, incidentally, is the meaning of the first letter of its acronym: Cascade Style Sheets).

Note: The version used was 3.3.3. They'll probably address this in the future.

For instance, there are situations where you need to override some style to customize existing components. Suppose you have a component used in various places, but in a specific location, you need it to have something different, and you only need to override a CSS property. Adding a new prop to the component to only use for this wouldn't be a good idea.

In the code below, due to the cascade effect, it's expected that the value white should replaced by black in the background property of ChildComponent. When we call this component, we add another background that should override the default.

In other words, everything declared later with the same specificity has a higher priority than the previous property.

The rendering of the div below would be <div class="bgWhite bgBlack" />.

import { ChildComponent } from './components'
import styles from './styles.module.css'
// .bgBlack { background: black; }

export default function ParentComponent() {
  return (
    <ChildComponent className={styles.bgBlack} />
  )
}

import styles from './styles.module.css'
// .bgWhite { background: white; }

export default function ChildComponent({ className }) {
  const bgStyles = [styles.white, className].join(' ')

  return (
    <div className={bgStyles}>
      Some Text
    </div>
  )
}

In Tailwind, if the rendering of your component is <div class="bg-white bg-black" />, the bg-black won't necessarily override the bg-white, as it depends on the internal order of classes in TW.

In other words, there is no guarantee of the cascade effect. Well, but that's what I pay CSS for! 😅

You can solve this, but guess what; you'll need to add another dependency to your project using tailwind-merge, which will remove the unwanted classes since the cascade effect doesn't work. Or use !important. 😒

Decision after Analysis

Finally, as previously mentioned, I have concluded that, for my case, the ideal would be to remove everything related to Tailwind (tailwindcss, postcss, tw-colors, and tailwind-merge) and use only CSS Modules (already provided by NextJs as the default).

I found the experience of using Tailwind juicy, but it didn't convince me 100%. I had to create many extra solutions and install packages to make my experience the way I think it works.

Using it for prototyping projects, MVPs, or even if the team consists only of backend developers (who don't want to learn CSS) it can work.

But if I were to create a new product, I would already rule out the use of Tailwind. To me, having well-organized design tokens with CSS variables and using CSS Modules is the most natural and efficient choice. I wouldn't even go for Sass. Doing the basics well is the trend for the coming years; it never stopped.

4 meses usando Tailwind

maiconsanson — Tue, 20 Feb 2024 14:55:48 +0000

English version

Este post foi escrito em outubro de 2023, alguns dados fornecidos aqui podem ter sido alterados.

Projeto pessoal é uma maravilha, você é livre para escolher toda a stack da aplicação: database, ambientes, deploy, testes, back end, front end, como organizar as tasks e etc. Nesses projetos você consegue ter um nível de aprendizado que dificilmente teria em uma empresa. Então aproveite, "brinque" de startup nas horas vagas e arque com suas decisões.

Meu foco é o front end mas navego um pouco no back end porque é uma sensação ótima conseguir, sozinho, tirar uma ideia maluca do papel e colocá-la em prática.

Sou um cara das antigas (+40) e que já trabalhava com desenvolvimento antes do início do Jquery e Prototype. Nunca fiz faculdade na área, mas sou formado em faculdade pública de Música e Belas Artes... pois é.

Enfim, só pra dizer que já vi muita coisa por aí. Conceitos e ideias que vão em e vem, problemas antigos com novos nomes e soluções velhas com nova roupagem.

Mas o que quero focar aqui é sobre estilos numa aplicação WEB.

Nos últimos anos, trabalhando como desenvolvedor sênior em empresas de vários tamanhos, cada vez mais fui me afastando do CSS que, modéstias a parte, conheço muito bem e sempre achei divertido e terapêutico. Nunca reclamei disso, é mais que comum utilizar algum Design System já projetado e você "só" vai programando os blocos (às vezes aplicando Atomic Design, que já renderia outro artigo, quando faz sentido) e sem se preocupar muito com o estilo dos componentes.

Quando precisa ajustar algo, geralmente o projeto utiliza algum CSS-in-JS como Styled Components, Emotion, Stitches, Linaria e etc. Eles são ótimos, usei por muito tempo e adoro usá-los quando faz sentido.

Certa vez eu utilizei Sass com CSS Modules para estilizar um teste prático de front end para uma vaga numa empresa de médio porte e um dos "programadores sêniors" me perguntou na entrevista:

Qual o motivo de usar Sass? É algo incomum hoje em dia. Por que você não escolheu CSS in JS? Não acha uma má prática voltar a usar CSS ou Sass?

Apenas sorri. Mas, ao longo do tempo, vi cada vez mais programadores front-end que não sabiam quase nada de CSS, Modules, Custom Properties, o poder do efeito em cascata e suas inúmeras possibilidades. Profissionais que já entram no mercado apenas utilizando JS/TS como padrão para escrever os estilos e veem CSS como algo obsoleto, fora de moda. Que loucura!

Voltando ao meu caso. Nesse projeto zero em folha, decidi usar Server Components junto com o NextJs e dar uma chance ao tão comentado TailWind Css. É um projeto relativamente complexo, com grande foco na experiência do usuário, com interface simples mas com detalhes de interações diferenciadas e múltiplos temas.

Posto isso, eis minhas conclusões após 4 meses de uso diário.

O que é o Tailwind CSS?

Em resumo, para quem caiu aqui de paraquedas, o Tailwind CSS é um framework de CSS como o antigo Bootstrap.

A diferença principal é que cada classe no Tailwind equivale a uma propriedade do CSS (ou pseudo classe/elemento) mas com o nome ligeiramente diferente. O chamado Utility-first.

Por exemplo:

A classe z-0 resulta na propriedade z-index: 0;.
A classe overflow-hidden resulta na propriedade overflow: hidden;.
A classe hover:underline resulta na pseudo classe :hover { text-decoration: underline; }

Estética controversa

Nos exemplos que lemos por aí, inclusive na própria documentação, encontramos este tipo de estrutura de marcação:

<div class="w-9 h-9 rounded-lg flex items-center justify-center text-slate-700 peer-checked:font-semibold peer-checked:bg-slate-900 peer-checked:text-white">

Eu ligo muito para estética funcional do código (beleza + facilidade de ler), clean code com bom senso e organização.

Ao ler o código acima, isso me causa incômodo. Acho difícil compreender rapidamente o que está acontecendo e perco o foco com todas essas classes que estão poluindo minha marcação.

Na minha opinião, marcação e estilo devem ser isolados o máximo possível. Eu não preciso saber que um elemento tem posição flex se não quero saber disso naquele momento.

Meu pensamento foi:

Tudo bem, são apenas exemplos, dá pra contornar. Vou criar uma função para lidar com isso.

E resolvi assim:

Cada componente, que continha algo estilizado, eu criei um styles.js.

import { cleanClasses } from '@helpers'

export default function classNames({ hasSomeProp }) {
  return {
    content: cleanClasses(`
      ${hasSomeProp ? 'border-green' : 'border-black'}
      border
      flex
      h-9
      items-center
      justify-center
      peer-checked:bg-slate-900
      peer-checked:font-semibold
      peer-checked:text-white
      rounded-lg
      text-slate-700
      w-9
    `),
  }
}

obs.: Sempre ordeno minhas propriedades em ordem alfabética.

E, dentro do meu componente, importei esse arquivo e apliquei ao elemento.

import classNames from './styles'

export default function MyComponent({ children, hasSomeProp }) {
  const c = classNames({ hasSomeProp } )
  return <div className={c.content}>{children}</div>
}

Resolvido, pensei eu!
Isolo todas as classes e deixo meu componente limpo! 🤘

Mas repare que no styles.js tem uma função chamada cleanClasses(). Eu tive que criá-la por conta da identação usando o template literals que estava zoando a minificação final do html.

Para resolver, e manter minha identação do jeito que acho que faz sentido, criei uma função para remover caracteres desnecessários que atrapalham a minificação no final do build.

import { isString } from '@helpers'

export default function cleanClasses(value) {
  if (!isString(value)) return ''

  const removeFalsyValues = value.replace(
    /\b(?:undefined|null|false|NaN|'')\b/g,
    '',
  )
  const removeExtraSpaces = removeFalsyValues.replace(/\s+/g, ' ')
  const cleanedClasses = removeExtraSpaces.trim()

  return cleanedClasses
}

Gostei da solução e me atendeu bem, mas já comecei a ficar com uma pulga atrás da orelha...

Eu gosto de programar mas sou preguiçoso, quanto menos eu programo mais eu gosto de programar. 😂

Abstrações desnecessárias

A documentação do Tailwind começou a ser parte do meu dia a dia de trabalho. Sempre havia uma aba aberta para eu consultar e ter certeza de que tal classe era a propriedade que eu queria.

E é normal, eu tenho que aprender o framework. Mas essa dependência em decorar classes, que são nomeações das propriedades (que eu já sabia de cór no CSS), começou a me irritar e achar as abstrações desnecessárias.

De certa forma, me atrevo a dizer, estava "desdecorando" as propriedades de CSS puro.

Usei esse termo de propósito pois depois de poucos meses usando TW, e já migrado o projeto para CSS Modules, eu me vi adicionando classes do Tailwind ao invés das propriedades de CSS. Como são nomes parecidos, meu cérebro simplesmente acabou substituindo esses valores.

Por exemplo, você sabe a qual propriedade a classe do Tailwind justify-center se refere?

🔘 justify-content: center;
🔘 justify-items: center;
🔘 justify-self: center;
🔘 justify-tracks: center;

Dica, justify-tracks ainda é experimental e nem existe no Tailwind.

Se você ficou na dúvida, vai ter que ir na documentação. 🤡

Lidando com seletores mais complexos

Um aspecto que não achei produtivo foi utilizar seletores mais complexos. Enquanto você estiliza apenas um único elemento é OK, mas quando precisa de algo mais complexo e que envolve outros elementos a coisa fica esquisita.

Por exemplo, digamos que eu precise modificar os itens, que não tenho acesso e não posso modificá-los, de uma lista.
obs.: Isso está longe de ser complexo.

<ul className={styles.ul}>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

Com Tailwind eu teria que adicionar algo como:

import { cleanClasses } from '@helpers'

export default function classNames() {
  return {
    ul: cleanClasses(`
      [&_li]:rounded-full
      [&_li]:border
      [&_li]:border-black
      [&_li]:bg-white
      [&_li]:px-2
      [&_li]:py-0.5
    `),
  }
}

É muito verboso dizer que cada propriedade é um item da lista com [&_li] e ter que informar isso, repetidas vezes, em cada classe do TW. Sem falar que não consigo usar shorthand properties. Tem plugin pra isso, mas não quero entupir minha aplicação com pacotes.

Com CSS eu apenas declaro como:

.ul li {
  background: var(--color__white);
  border-radius: var(--radius__full);
  border: 1px solid var(--color__black);
  padding: var(--size__0-5) var(--size__2);
}

E nem vou entrar em detalhe de sibling selectors e outros seletores que são triviais com CSS nativo. Sinto-me reinventando a roda mas essa roda não é lá muito redonda. 😂

Temas

Outra coisa que não gostei foi a forma de adicionar múltiplos temas e seus diversos design tokens usando o TW. Pensei que ele lidaria com isso de forma nativa, mas não.

Uma possibilidade é instalar mais uma dependência como a tw-colors, já que não temos isso nativamente no framework (só podemos alterar os tokens do tema atual). Ela é muito boa e funciona bem.

Outra possibilidade é usar as variáveis de CSS nativas e informar ao Tailwind como usá-las... mas pera aí, eu não quero isso já que escolhi o framework para lidar com os estilos. Quero apenas usar o Tailwind e sua turminha.

Cadê o efeito em cascata?

Rapidamente aprendi que o TW remove uma das coisas mais importantes do CSS (que, inclusive, é o significado da primeira letra do seu acrônimo: Cascade Style Sheets.

obs.: A versão usada foi a 3.3.3, provavelmente vão resolver isso no futuro.

Por exemplo, há situações em que você precisa sobrescrever algum estilo para customizar componentes já existentes.
Vamos supor que você tenha um componente que é usado em vários lugares, mas, num único lugar específico, você precisa que ele tenha algo diferente e só precisa sobrescrever uma propriedade de CSS. Adicionar uma nova prop ao componente, que só vai ser usada ali, não seria uma boa ideia.

No código abaixo, em função do efeito em cascata, espera-se que o valor white seja substituído pelo black na propriedade background do ChildComponent. Porque quando chamamos esse componente adicionamos um outro background que deve sobrescrever o default.

Ou seja, tudo o que está declarado depois e com a mesma especificidade, tem uma ordem de importância maior que a propriedade anterior.

A renderização da div abaixo seria <div class="bgWhite bgBlack" />

import { ChildComponent } from './components'
import styles from './styles.module.css'
// .bgBlack { background: black; }

export default function ParentComponent() {
  return (
    <ChildComponent className={styles.bgBlack} />
  )
}

import styles from './styles.module.css'
// .bgWhite { background: white; }

export default function ChildComponent({ className }) {
  const bgStyles = [styles.white, className].join(' ')

  return (
    <div className={bgStyles}>
      Some Text
    </div>
  )
}

Já no Tailwind, se a renderização do seu componente for <div class="bg-white bg-black" /> o bg-black não necessariamente sobrescreverá o bg-white, porque isso vai depender da ordem interna de classes do TW.

Ou seja, não há garantia que o efeito cascata seja aplicado! Poxa, mas é para isso que pago o CSS! 😅

Você consegue resolver isso, mas, adivinha, vai precisar acoplar mais uma dependência ao seu projeto usando o tailwind-merge que irá remover as classes indesejadas já que o efeito em cascata não funciona. Ou usar o !important. 😒

Decisão após análise

E, finalmente, como já foi dito, cheguei a conclusão que, para o meu caso, o ideal seria remover tudo relacionado ao Tailwind (tailwindcss, postcss, tw-colors e tailwind-merge) e usar apenas CSS Modules (já fornecido pelo NextJs como padrão).

Achei interessante a experiência de usar o Tailwind mas não me convenceu 100%. Tive que criar muitas soluções extras e instalações de pacotes para deixar minha experiência do jeito que acho que funciona.

Para projetos de prototipação, MVPs, ou até mesmo se a equipe seja apenas de devs back-end (que não querem aprender CSS), pode ser.

Mas se eu for criar um novo produto eu já descarto o uso do Tailwind. Ter um design tokens organizado com variáveis em CSS e usar CSS Modules é a escolha mais natural e eficiente pra mim. Nem de Sass eu iria. O básico bem feito é a tendência para os próximos anos, na verdade nunca deixou de ser.

Enfim, voltei a ter prazer em escrever e ler CSS.