Nov 13, 2019
PostCSS x Sass
O que é esse negócio de PostCSS que tá na moda?
Antes de começar, quero deixar claro e explícito que esse post expressa a minha opinião sobre essas ferramentas (além de uma breve história sobre o cenário); você pode concordar ou discordar da minha opinião.
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.
Você pode encontrar o catálogo de plugins para PostCSS nesse site:
https://www.postcss.parts/
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.
Veja aqui um benchmark de performance entre pré-processadores x PostCSS:
https://github.com/postcss/benchmark
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?
Mentira; use se quiser!
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!
