Ainda há necessidade de usar pré-processadores CSS?

[victornery]

E aí, pessoal. Tudo tranquilo?

Aqui na agência, nós estamos imergindo no mundo do React e nosso líder comentou que, com a chegada de algumas soluções para CSS, como o CSS Modules, perdia-se o sentido de utilizar pré-processadores CSS (Aqui, utilizamos Gulp como task-runner e Sass como pré-processador by default).

De fato, o escopamento local (além dos poderes atuais do CSS Vanilla) proporcionado pelo CSS Modules (em união de Webpack + React), retiram o sentido de se utilizar SASS em algum projeto mais novo.

O que vocês acham disso, pessoal?

[evertonthepaula]

Lí superficialmente sobre ele e não entendi para se sincero. A ideia é manter o css com escopo local sempre quando se utiliza "web components", mas em teoria um componente já faz isso. No meu ver não resolve alguns problemas do css que a comunidade gostaria como problemas de design e arquitetura css, para outros problemas que ele substitui o trabalho do sass, o css moderno e web componentes conseguem resolver também sem pré-processadores.

Meus dois centavos de quem não conhece bem a ferramente ok? Não haverá a necessidade de pré-processadores em breve, mas não será por causa do css modules.

Estou aberto a outras idéias. :)

[victornery]

Interessante, @evertonthepaula. Que problemas seriam esses que o SASS faz que faz falta no CSS Modules?

Digamos, eu não consigo criar Loops com CSS Modules, mas é algo bem específico de, tipo, Grid. Você pode inclusive estender outras classes usando o compose dele.

Acho show ainda a ofuscação das classes.

[felipefialho]

Fala @victornery, tudo bem?

Precisamos separar os conceitos.

Pré-processadores

Pré-processadores como Sass, Stylus e etc, são amplamente utilizados por tornarem o CSS mais poderoso, adicionando lógica através de mixins, variáveis, nesting e várias outras features que melhoram drasticamente as possibilidades e a manutenção do código.

Atualmente já temos a possibilidade de usar algumas features do Módulo 4 do CSS (next-css pode ajudar aqui), como variáveis dinâmicas. Ainda temos a opção de usar PostCSS para adicionar features de pré-processadores conforme a necessidade.

Isso de fato faz com que a atração dos pré-processadores diminua um pouco.

CSS Modules, Styled Components, etc

O objetivo dessas soluções é completamente diferente. Elas servem para resolver o principal problema do CSS: A especificidade.

Ou seja, com eles é possível criar módulos igual no JavaScript, o que resolve problemas de escopos diferentes brigarem entre si, colisão de classes e etc.

Inclusive, é super comum o uso dessas libs junto com pré-processadores, elas não se anulam.

Exemplo disso, é meu boilerplate Kratos, onde utilizo CSS Modules com Sass ou Stylus.

[ninetails]

Assim, achei o título bem clickbait rs. Pois não acho que pré-processador irá "morrer".

Agora entrando no contexto da mensagem e especificando para ecossistemas React: É tudo questão de tooling. Fica redundante utilizar pré-processador com componentes estilizados (styled-components, Radium, Glamorous, emotion...) pois a maioria deles já possui pós-processadores (nem que seja só o autoprefixer) e é JavaScript, tudo o que dava pra fazer de mixins/functions é possível fazer no JS.

Mas não acho que ficaria redundante para CSS Modules. Só precisa colocar como loader pro webpack :D

[victornery]

Fala @victornery, tudo bem?

Precisamos separar os conceitos.

Pré-processadores

Pré-processadores como Sass, Stylus e etc, são amplamente utilizados por tornarem o CSS mais poderoso, adicionando lógica através de mixins, variáveis, nesting e várias outras features que melhoram drasticamente as possibilidades e a manutenção do código.

Atualmente já temos a possibilidade de usar algumas features do Módulo 4 do CSS (next-css pode ajudar aqui), como variáveis dinâmicas. Ainda temos a opção de usar PostCSS para adicionar features de pré-processadores conforme a necessidade.

Isso de fato faz com que a atração dos pré-processadores diminua um pouco.

CSS Modules, Styled Components, etc

O objetivo dessas soluções é completamente diferente. Elas servem para resolver o principal problema do CSS: A especificidade.

Ou seja, com eles é possível criar módulos igual no JavaScript, o que resolve problemas de escopos diferentes brigarem entre si, colisão de classes e etc.

Inclusive, é super comum o uso dessas libs junto com pré-processadores, elas não se anulam.

Exemplo disso, é meu boilerplate Kratos, onde utilizo CSS Modules com Sass ou Stylus.

Entendi, @lfeh!

O que quis dizer é que, como disse o @ninetails, num ecossistema React, ele torna a utilização redundante pro dev. Estamos testando lá na agência e também estou testando em alguns projetos pessoais, tive um resultado bem satisfatório.

Senti falta do Sass nos seguintes momentos:

• Criação de Grid (A diretiva @for do Sass facilitava bastante)
• Criação de transições utilizando :nth-child(n) (Mais uma vez, saudade da diretiva @for)

Ainda não testei a fundo como o composes funciona, mas ele quebra um galho na situação de estender - ou seja, compor - outras classes.

[ninetails]

Calma rs,

O que quis dizer é que, como disse o @ninetails, num ecossistema React, ele torna a utilização redundante pro dev. (...)

O que eu falei é que é redundante utilizar com libs de componentes estilizados (styled-components, Glamorous, emotion, Radium...), não com css modules.

Mas se for só CSS Modules ainda sim pode ser necessário o uso para adicionar algumas funcionalidades como autoprefixer, mixins etc. Você consegue utilizar o sass com ele (configurando corretamente o loader do Webpack).

Já pra componentes estilizados, a idéia é fazer isso no JS.