PostCSS x Sass

Photo by Maarten van den Heuvel on Unsplash

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!

--

--

--

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

Love podcasts or audiobooks? Learn on the go with our new app.

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

Julio Lozovei

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

More from Medium

Masai Collaboration Project- HomeDepot Clone

7 FREE Sites For Web Developers You Probably Didn’t Know Existed

How to build beautiful scroll indicators in Vue.js

How to Create a Sleek Preloader Animation Using GSAP Timeline