5186 sujets

Le Bar du forum

Pourra-t-on se passer de préprocesseur (SCSS…) en 2026 ?

CSS a beaucoup progressé depuis l'époque où j'ai commencé à m'en servir (CSS 2.1) et certains des outils spécifiques aux préprocesseurs (SCSS…) ont été ajoutés à CSS (variables, imbrications Smiley nesting ). Dans ce contexte et en fonction de mes usages, les préprocesseurs ont perdu un peu de leur intérêt (reste les mixins) tout en gardant leur lourdeur (compilation). Je me suis donc posé la question : utiliser un préprocesseur sera-t-il encore utile en 2026 ? J'ai mon idée sur la question, mais quelle est la vôtre ?
Modifié par Derwoed (18 Dec 2025 - 17:42)
Modérateur
bonjour !

Pourquoi faire l'impasse aux structures de contrôle, aux functions, aux mixins par défault et customisables, aux types de variables, etc. ?
Administrateur
Hello,

En ce qui nous concerne, nous n'utilisons plus de preprocesseurs dans nos projets depuis plusieurs mois. CSS natif a quasiment comblé toutes ses lacunes, et pour le reste il y a des bundlers (vite) et PostCSS.
Bonsoir,

Idem pour moi. J'ai laissé tomber il y a deux ans, avec un très léger appui de PostCSS (très léger, car son écosystème des plugins est hyper volatile, rapidement legacy, il ne vaut mieux pas trop y compter dessus).

Ce sont les custom properties qui se sont révélées décisives pour moi, non parce qu'elles font office de variables car, en réalité, elles font bien mieux que cela. Elles évitent notamment le recours aux mixins qui encourageaient à de mauvaises pratiques, avec notamment la génération de classes CSS telles qu'on les a connues à une époque (ex : span2, span3, offset2, grid4, etc). Face à cette génération de code qui pouvait se révéler conséquente les customs properties sont une solution élégante qui allege de beaucoup le CSS, donc plus besoin de mixins, donc plus besoin de pré-processeurs.
Modifié par Olivier C (19 Dec 2025 - 20:53)
Modérateur
C'est vrai que la question peut se poser de nos jours.

Cependant, le SASS est selon moi encore intéressant dans le web classique. Je pense à cet instant à une manip que je fais depuis des lustres maintenant. Je déclare mes fonts dans un map. Ensuite, je fais un each pour les charger. J'utilise aussi une mixin pour gérer mes breakpoints. J'utilise une mixin pour créer des triangles. J'ai aussi des fonctions pour gérer rem => px et px => rem.

Dans un contexte React, VueJS, Svelte, etc. il est exact que le SASS peut perdre de son intérêt. Mais, on peut tout de même faire ceci :
vuejs/svelte : 

<style lang="scss">
  @use './scss/config/vars' as vars;
  @use './scss/config/mixins' as mixins;

  /* etc. */
</style>
Ah oui, le SCSS directement dans Vue.js c'est intéressant !
Pour les mixins, il ne me reste que quelques cas d'usage mais assez rares au final, par esprit DRY j'ai mis un plugin PostCSS pour m'en servir, mais je pourrais m'en passer ; dans tout mon CSS ça concerne 2 usages, celui-ci est l'un d'entre eux :

@mixin progress-value-bar {
  min-width: 1em;
  background-color: var(--color);
  background-image: repeating-linear-gradient(-45deg, transparent 0 0.5rem, var(--colorA2) 0.5rem 1rem);
  background-size: calc(1rem / cos(45deg)) 100%, 100% 800%;
  background-position: inherit;
  box-shadow: inset 0 2px 9px var(--colorA3), inset 0 -2px 6px var(--colorAB4);
  border-radius: 0.5em;
}

.progress {
  /* Extrait du code */
  /* Ces 2 sélecteurs ne peuvent pas être regroupés : */
  &::-webkit-progress-value {
    @include progress-value-bar;
  }

  &::-moz-progress-bar {
    @include progress-value-bar;
  }
}

Modifié par Olivier C (20 Dec 2025 - 09:23)
Administrateur
J'apporte quelques précisions par rapport à ma réponse courte d'hier.

De manière générale, la stack commune à tous nos projets est celle-ci :

Environnement / compilation
- pnpm : gestionnaire de paquets
- Vite : bundler/outil de compilation

Linters / qualité
- Editorconfig : indentation, encodage, EOL
- Prettier : formatage automatique
- Stylelint : vérification CSS
- ESLint : vérification JavaScript/TypeScript (+ frameworks)

Concernant CSS précisément :
- On laisse petit à petit tomber Tailwind / UnoCSS parce qu'on dispose de nos propres outils : Bretzel pour les layouts utilitaires, KNACSS pour les styles des composants HTML natifs, et Primary, un outil interne pour assembler tout ça.
- On n'utilise plus aucun mixin Sass depuis bien longtemps, mais on est impatients de pouvoir se servir des @function CSS pour des snippets bien pratiques (ex. https://sindresorhus.com/css-extras/)
- Tout ce qui nous manque vraiment par rapport à Sass sont les Media Queries avec des variables (les Custom Media, qui sont loin d'être utilisables à l'état natif aujourd'hui) et c'est pour ça qu'on passe par un plugin PostCSS : postcss-custom-media.

Voilà voilà.
Prévenir un modérateur
Répondre au sujet
Aller à