Mixins ou @extend?

[felipefialho]

Acabei de ler um artigo da csswizardry chamado Mixins Better for Performance.

O autor mostra que por incrível que pareça, um CSS que não usa @extend e sim mixins, é menor na versão final (com gzip) do que um CSS que usa @extend.

Eu realmente não fazia ideia disso. Obviamente, na versão minificada, o CSS com @extend vai ser bem menor, então sempre usei bastante o @extend para não duplicar blocos de código igual.

Mas ainda não estou totalmente decidido. O que pensam sobre isso?

[bernardodiasc]

O @extend funciona dentro de media queries? Acho que esbarrei em algum problema assim no passado e parei de usar.

[felipefialho]

Não funciona @bernardodiasc, eu coloco fora da media queries (até porque, boa parte dos extends, já vem com um bloco de media queries junto).

To na dúvida pra carario agora. Teria que dar uma restruturada geral no projeto.

A vantagem de tirar o @extends seria além dessa melhora de performance, segundo o artigo, uma melhoria na velocidade na hora de gerar o CSS...

E agora? haha

[bernardodiasc]

Só pra confirmar, @extend agrega todos os seletores estendidos em um bloco só e o mixin inclui propriedades naquele seletor específico resultando duplicação de estilos. Correto? Mas sobra uma dúvida, os blocos estendidos resultantes vão pra onde na folha de estilo, pois a ordem das propriedades altera o resultado. Isso faz parecer meio arriscado e pode acarretar em treta com especificidade. Digamos, se estendo as propriedades de um botão, os estilos do segundo botão vão parar junto com o anterior ou vão para o final do arquivo por exemplo? De qualquer modo parece que vai sair do lugar, e se precisar sobrescrever um background por exemplo, como faz?

Desculpa perguntar tanto, só tive uma expêriencia complicada com extend e mudei pra mixin, acabei sem entender direito como funciona.

[fernandofleury]

@bernardodiasc isso vai depender da inteligência do preprocessador, e em seguida na inteligência da minificação que está sendo aplicada.

Por exemplo, a ferramenta no caso, vai tentar agrupar os seletores no que for possível. Então se você simplesmente sair lançando extend sem outras declarações nessas regras, todas ficam agrupadas em um único seletor, tipo:

%color {
 color: red;
}

.button {
 @extend %color;
}

.panel {
 @extend %color;
}

.reveal {
 @extend %color;
}

gera:

.button, .panel, .reveal {
 color: red;
}

agora algo como:

%color {
 color: red;
}

.button {
 @extend %color;
 border-color: red;
}

.panel {
 @extend %color;
}

.reveal {
 @extend %color;
}

gera:

.button, .panel, .reveal {
 color: red;
}

.button {
 border-color: red;
}

[fernandofleury]

Agora considerando a utilização de um mixin:

@mixin color() {
 color: red;
}

.button {
 @include color;
}

.panel {
 @include color;
}

.reveal {
 @include color;
}

gera:

.button {
  color: red;
}

.panel {
  color: red;
}

.reveal {
  color: red;
}

Aí utilizando qualquer ferramenta com inteligência de minificação (juro, até cssminify online se vira bem com isso):

.button,.panel,.reveal{color:red}

[fernandofleury]

Então o ponto é a complexidade final gerada/complexidade na hora de escrever código, principalmente considerando que todo mundo usa alguma ferramenta pra lidar com essa minificação.

Eu particularmente gosto da ideia de uma utilização única! Considerando que o mixin pode se responsabilizar desde fornecer uma simples declaração como border-radius: 4px até algo mais complexo como parâmetros e controles de circuitos pra gerar o estilo final.

Outro ponto é como você usa o extend e como isso pode prejudicar a clareza/limpeza do código, mas aí eu acho que isso é influência do próprio desenvolvedor... Pensando que é super nojento dar um extend em uma .class, ou qualquer outro seletor já existente, mas eu acho que isso não deveria ocorrer comumente. A ideia desses caras é trabalhar com metadados, o placeholder usando a "silent class" dele, vide % e o mixin com a declaração explícita da diretiva @mixin.

Quando levamos isso pro postcss (olha lá eu fazendo jabá denovo), é encorajado a utilização das diretivas em ambos casos, vide: @define-mixin e @define-placeholder, então o ponto de "é menos código" não faz muito sentido aqui né?

Não acho que todo mundo deve sair por aí correndo desfazendo tudo em todos os projetos. Mas é um excelente ponto de atenção para padronizarmos como escrevemos nosso CSS, e solidificar as features que julgamos essencial em um workflow. Afinal é um plugin a menos se trabalharem com postcss :)

[bernardodiasc]

Legal, po super bem explicado! Valeu @fernandofleury!

Considerando que os benefícios do extend podem ser conseguidos de outra etapa sem problema e parece que requer uma certa arquitetura bem definida no projeto como OOCSS para a escrita, e parece bem razoável usá-lo se esse for o caso, mas se não for o caso da arquitetura vejo mais possíveis problemas do que soluções, digo, todas as regrinhas que puder deixar na etapa de automatização, seria minha opção. Mas to pensando só no caso de extender classes, o caso de placeholders to sabendo agora e me parece muito útil. Ainda assim se extend com placeholder gera o mesmo resultado que um mixin mais um plugin (que provavelmente ja vai estar rodando em qualquer caso), acho que optaria por mixins, ja que o resultado é o mesmo.

Experiências que tive em times grandes é que todo mundo acaba cutucando o css e nem todos se preocupam ou sabem das regras nominais, dessa forma sempre funcionou melhor quando há menos regras de desenvolvimento e mais processos automáticos. Um exemplo, bem controverso, foi um caso que optei por remover o compass de um projeto simplesmente pela falta de consistência que cada dev escrevia, alguns usavam mixins da lib outros não, por exemplo casos de usar mixin apenas pelos prefixos sendo que o autoprefixer ja estava instalado, etc, quando removi a lib, refiz alguns mixins e ficou tão bom quanto e alcançei a consistência que queria na escrita. A ideia seria simplificar e incluir menos coisas o máximo possível, e aumentar a complexidade somente se houver necessidade ou um benefício grande e se a equipe inteira souber trabalhar consistentemente com essas adições.

To curioso pra saber mais opiniões, tambem vou tirar um tempo pra ler o artigo citado pelo @LFeh :)

[felipefialho]

Vamos lá, 5 dias após ler tudo que falaram (sensacional @fernandofleury <3) e tomar a decisão de não usar @extends passando a usar apenas mixins, cheguei as seguintes conclusões:

• Plugins como o nanocss já fazem o trabalho do @extends caso você queira, basta ativar ou desativar essa opção, sendo assim, faz muito mais sentido deixar isso para a etapa final do código.
• Mixins de fato são muito mais intuitivos e gostosos de trabalhar, é possível criar uma cadeia com várias opções e usar conforme necessário. Como usava muitos @extends, mal aproveitava essas vantagens dos mixins.
• A velocidade para compilar o código aumentou drasticamente.
• Sinto a organização mais efetiva e lógica agora.

[bernardodiasc]

Comecei a usar CSS Modules a pouco tempo e conheci a propriedade compose que funciona com a mesma ideia do @extend pelo css module. Esse artigo é o original sobre css modules http://glenmaddern.com/articles/css-modules, super recomendo a leitura.

[abnersajr]

Outra vantagem dos mixins, se tratando de SASS (não sei os outros pois não utilizo) é poder usar operadores lógicos, outros mixins, passar variáveis, listas e etc. Já o @extends não possibilita isso.

[felipefialho]

Exato @abnersajr e mais um ponto que tenho abordado nos últimos Meetups:

• Podemos deixar a tarefa de "criar" os @extends para plugins tipo o cssnano e ativar e desativar conforme o gosto. Tirando assim a poluição e os problemas que os @extends geram nos códigos.