PostCSS x Sass

O que é esse negócio de PostCSS que tá na moda?

Photo by Maarten van den Heuvel on Unsplash

Falar sobre CSS sempre gera um certo frisson nos desenvolvedores — sejam eles back ou front-enders, e até mesmo em desenvolvedores de outras áreas (mobile, embarcados…). Na minha opinião, uma das linguagens mais desprezadas no mundo da programação; apesar de ser uma das bases da web.

Ao longo da última década (começando ali em meados de 2009) a web tem evoluído a passos largos: novas tecnologias surgiram para melhorar e facilitar o desenvolvimento, automações para todos os lados… Vimos o despertar de um novo JavaScript com a especificação do ES5 (e agora do ES6, ES7, ES8…), vimos o surgimento do NodeJS e frameworks mais modernos como o React e Vue — muita coisa mudou (para melhor)!

E também vimos essa evolução dentro do CSS — frameworks como less e Bootstrap trouxeram mais agilidade na hora de criar os estilos — sem precisar criar tudo do 0 sempre.

Mas, logos vimos também uma grande dependência desses frameworks — ainda hoje existe muito desenvolvedor que só sabe criar layout com eles (e não há nada de errado com isso; apenas quero deixar claro que hoje existem formas mais rápidas e melhores).

Em meio aos frameworks de CSS surgiram também alguns conceitos interessantes: os pré-processadores e os pós-processadores. Abaixo irei falar um pouco sobre os dois, e como foi minha experiência utilizando essas duas abordagens.

Pré-processadores

Ferramentas como o Sass (que é lá de 2006) e o Stylus (2011) vieram para automatizar vários fluxos que eram repetidos e se tornavam gargalos na hora do desenvolvimento — por exemplo, fazer o autoprefixing das propriedades para ter maior compatibilidade, melhorar a semântica visual do código (com as regras de nesting), o uso de variáveis para aplicar o princípio DRY e evitar aquele código fragmentado (imagine o trabalho que era sair procurando todas as regras de cor que você precisa!), e ainda uma série de funções bacanas para ajudar: funções para gerar tons de cores, criar mixins, minificar código…

Esses dois que eu citei acima (Sass e Stylus) se encaixam na categoria de "pré-processadores". Na prática isso significa que você vai usar eles antes do seu CSS:

/* usando sintaxe padrão */
body
{
color: white;
}
/* usando sintaxe otimizada */
body

color: white
/* usando sintaxe sem pontuações */
body

color white

irão ser interpretados/compilados para:

body {
color: white;
}
/* ou, se você gerar um build minificado */
body { color: white }

Esse conceito de fato é muito bom — tanto que ainda hoje as duas ferramentas são utilizadas em larga escala. A implementação do Sass foi feita em Ruby; e como resposta a ele surgiu o Stylus que utilizava apenas JS.

Pós-processadores

Com o surgimento do PostCSS (por volta de 2013), o conceito de pós-processamento no CSS ganhava mais força. O objetivo era simples: ser mais rápido do que os pré-processadores.

Com os pré-processadores você precisa carregar todo o ecossistema antes do seu CSS, mesmo que você não utilize todas as funções que ele disponibiliza.

Já com os pós-processadores você tem a liberdade de escolher tudo aquilo que irá precisar — funções para cores, mixins, minificadores, autoprefixers, regras customizadas (e afins).

Falando especificamente do PostCSS, o workflow é mais ou menos assim:

  • você escreve o seu código CSS, sem a necessidade de seguir uma sintaxe específica (sass-like)
  • no processo de build, você diz para o PostCSS quais plugins vai precisar: autoprefixer, clean, nested…
  • o PostCSS irá processar o seu código com esses plugins e irá gerar um novo output CSS, que poderá ser utilizado em produção.

Qual a diferença?

Ambos geram outputs CSS, a diferença está no processo; e na minha opinião, nas dependências.

Tudo no PostCSS é um plugin: seja para escrever as regras com nesting, para criar media queries customizadas, ou então para criar seletores customizados.

Através dos plugins você diz quais serão as utilidades que você precisará no projeto, deixando mais fácil de entender quais são as dependências e o que está sendo utilizado no processo de build — muito mais fácil para identificar possíveis gargalos.

E esses plugins são todos escritos em JavaScript — ou seja, tudo em apenas uma linguagem (sem a necessidade de bindings para Ruby e/ou Python).

Por que eu comecei a usar?

Eu já usava o Sass há um bom tempo quando experimentei pela primeira vez o PostCSS (isso foi no começo de 2018 eu acho); por conta disso, estava bem acostumado a configurar os projetos, usar algumas funções e helpers…

Aprender qual era a diferença e como funcionava o pós-processamento foi um grande incentivo para a mudança — pelo menos entender um novo jeito de escrever CSS.

Depois de vários testes eu percebi que com o PostCSS as coisas ficavam mais rápidas — principalmente o processo de build dos arquivos. Como no Sass precisamos "carregar" todo o ecossistema antes de gerar o build, dependendo do tamanho das folhas de estilo e do número de imports que eu fazia gerava um certo gargalo.

A ideia de carregar sob demanda aquilo que eu de fato precisava para gerar o output final me atraiu bastante — muitas vezes vejo vários projetos que utilizam Sass, mas não utilizam nem metade das funcionalidades que ele oferece; uma comparação parecida seria "importar o jQuery apenas para adicionar/remover classes dos elementos".

Outro ponto que me fez considerar essa migração (apesar de ainda usar o Sass em alguns projetos) eram duas coisas que são impossíveis ou chatas de fazer com o Sass:

1 — Autoprefixing

Se você já precisou dar suporte para navegadores antigos usando Sass, provavelmente fez um ou mais mixins parecidos com esses:

/* https://css-tricks.com/snippets/sass/mixin-prefix-properties/ */
@mixin prefix($property, $value, $prefixes: ()) {
@each $prefix in $prefixes {
#{'-' + $prefix + '-' + $property}: $value;
}

// Output standard non-prefixed declaration
#{$property}: $value;
}
/* handmade */
@mixin autoprefixer($prop, $value) {
#{'-webkit-' + $prop}: $value;
#{'-moz-' + $prop}: $value;
#{'-ms-' + $prop}: $value;
#{'-o-' + $prop}: $value;
#{$prop}: $value;
}

E com certeza eles vão funcionar bem — o problema é sempre ter que fazer isso. Com o PostCSS você não precisa se preocupar com esse tipo de coisa — ele já possui um autoprefixer embutido.

2 — Utilizar specs novas

Todo desenvolvedor curioso vai (pelo menos tentar) usar novas specs das linguagens — com CSS isso não é diferente.

No Sass isso é impossível; já no PostCSS existe o plugin postcss-preset-env (o antigo cssnext). Com ele você consegue usar specs novas do CSS sem se preocupar com suporte nem fallbacks.

E você, quando vai começar a usar?

Apesar da brincadeira, nós enquanto desenvolvedores precisamos parar de defender tecnologias e defender o valor que conseguimos entregar através delas. Isso é, colocar a "tecnologia" no seu devido lugar — que é o meio, o caminho; e nunca o objetivo final/valor a ser entregue.

Eu percebi que conseguia entregar mais valor usando o PostCSS, e por isso comecei a adotar ele com maior frequência — seja por ele ser mais rápido e mais direto naquilo que eu precisava.

O Andrey Sitnik (criador do PostCSS) tem duas palestras que me ajudaram a entender melhor onde cada uma dessas tecnologias estavam e qual o objetivo dessa nova forma de processar CSS:

Espero que elas também possam te ajuder a entender essa nova perspectiva.

Meu objetivo com esse texto não é persuadir você a abandonar o Sass e mergulhar de cabeça no PostCSS — bom, se você quiser fazer isso, vai fundo; o objetivo aqui é mostrar uma forma diferente de processar o seu CSS.

Quando falo sobre PostCSS x Sass vejo muitos desenvolvedores front-end torcerem o nariz — e a maioria faz isso porque não conhece a outra forma (a outra parte faz isso por ignorância mesmo, ou seja, conhece mas tem medo de aprender/arriscar).

Comentários, críticas, opiniões, cases e afins sempre são e serão bem-vindos!

--

--

Human, front-end developer, amateur musician, writer and speaker; problem solver. https://jlozovei.dev

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Julio Lozovei

Human, front-end developer, amateur musician, writer and speaker; problem solver. https://jlozovei.dev