Migrar de Sass para CSS nativo ficou viável (e mais fácil com IA)

Por que migrar

Durante anos, Sass ampliou o CSS com variáveis, funções, aninhamento e outros recursos. A avaliação apresentada é que o CSS nativo alcançou essas capacidades e, salvo em casos muito específicos, Sass deixou de ser necessário para novos projetos. Em projetos antigos, mantê-lo também não representa, por si só, um problema de segurança, porque o código é compilado para CSS durante a etapa de build e não chega ao navegador.

Ainda assim, a migração pode trazer benefícios. Usar ao mesmo tempo propriedades personalizadas do CSS e variáveis do Sass gera confusão e duplicação. A eliminação dos arquivos CSS gerados reduz o que precisa ser mantido e copiado durante a implantação, o build pode ficar ligeiramente mais rápido, a dependência do compilador pode ser removida e há uma tecnologia a menos para os desenvolvedores aprenderem. O processo pode ser feito manualmente ou com auxílio de IA.

Etapas e cuidados

O primeiro passo é localizar todos os arquivos .scss e, depois, identificar recursos exclusivos do Sass, como mixins, funções nomeadas e lighten(). Esses trechos devem ser substituídos por funções nativas do CSS ou pelos valores já compilados nos arquivos CSS existentes. Também é necessário trocar comentários com // pela sintaxe /* ... */, pois a primeira não é aceita pelo CSS nativo e pode impedir a interpretação das regras seguintes.

Em seguida, devem ser removidos os CSS, arquivos minificados e mapas gerados pelo compilador, sem apagar arquivos CSS escritos manualmente. Os arquivos .scss restantes podem ser renomeados para .css, desde que já não contenham recursos exclusivos do Sass. Todas as referências às extensões antigas precisam ser atualizadas, inclusive em elementos link e propriedades como styleUrl. Em projetos .NET, o arquivo do projeto também deve listar corretamente os arquivos dentro de <Content>, pois essa configuração determina o que será copiado na implantação.

Depois da renomeação, recomenda-se reconstruir o projeto, verificar erros, executar testes automatizados quando existirem e inspecionar manualmente as páginas. Uma regra CSS ausente pode falhar silenciosamente e ser difícil de perceber. Por fim, é possível remover o pacote ou a extensão que compilava Sass e apagar configurações remanescentes, procurando por referências a .scss.

Imports e desempenho

Sass permite dividir os estilos em parciais, como _forms.scss e _tables.scss, e reuni-los em um único CSS. No CSS nativo, @import ocorre em tempo de execução e provoca uma requisição secundária, que precisa ser executada sequencialmente após a primeira. Uma alternativa sugerida é incluir vários arquivos CSS pequenos diretamente na página ou no modelo. Com HTTP/2, as requisições podem ocorrer em paralelo, o que pode ser mais rápido que uma única requisição longa.

A recomendação, porém, não é universal: se a estratégia de importação ou agrupamento for alterada, o desempenho deve ser medido. Dependendo do resultado, pode ser necessário agrupar arquivos no servidor, aplicar minificação ou adiar CSS não crítico para melhorar o carregamento da página.