Cela fait plusieurs années que nous avons l’habitude d’utiliser le préprocesseur SASS (Syntically Awesome Style Sheets) chez JoliCode. Incontournable chez les intégrateur·rice·s, il permet d’utiliser des variables, faire des boucles, créer des mixins…
Mais avec les avancées du langage CSS qui permet d’utiliser des custom properties et bientôt de faire de l’imbrication, la pertinence de son utilisation commence à se poser. J’avoue, à titre personnel, être très adepte du « pourquoi changer si ça fonctionne ? » J’aime mes petites habitudes, mon confort et j’ai un peu peur d’être frustrée en changeant d’outil.
Un de mes collègues a travaillé sur un nouveau gabarit de projet Symfony qui utilise PostCSS mais se passe de SASS. Lorsque j’ai eu l’opportunité de travailler sur le site cacharel.fr, un petit projet de quelques pages, je me suis alors dit qu’il était peut-être temps pour moi de sortir un peu de ma zone de confort et d’expérimenter un projet sans SASS.
J’utilise déjà PostCSS depuis de nombreuses années. Il me permet a minima d’utiliser autoprefixer pour ajouter les préfixes CSS qui vont bien sur les règles encore peu supportées par les navigateurs. PostCSS diffère de SASS dans le sens où SASS est un préprocesseur qui propose par défaut un certain nombre de fonctionnalités. PostCSS par défaut ne fait rien, ça n’est pas un préprocesseur, c’est un outil qui nous permet de modifier du code CSS à l’aide de JavaScript. On va pouvoir l’agrémenter de plugins pour y ajouter, par exemple, les fonctionnalités d’un préprocesseur...
[Courte citation de 8% de l'article original]