Depuis un petit moment, je n’arrête pas d’entendre parler de pré-processeurs CSS, comme Sass, LESS, ou Stylus. Ces outils ajoutent de nouvelles fonctionnalités à vos CSS (comme des variables, des fonctions ou des snippets) en générant votre code côté serveur. Parfois ça donne un peu envie, mais la plupart du temps vraiment pas (voire pire encore).
Lea Verou résume parfaitement mes appréhensions sur ce genre d’outils :
- Les pré-processeurs faussent notre perception de la taille finale d’une feuille de style, et ça peut être difficile d’optimiser correctement le tout
- Les pré-processeurs rendent plus difficile la routine classique de débuggage, où les numéros de lignes visibles dans Firebug (ou équivalent) ne correspondent pas à votre CSS
- L’utilisation de pré-processeurs en équipe nécessite que toute l’équipe maîtrise l’outil
- Les fonctionnalités apportées par les pré-processeurs finiront par arriver dans les spécifications officielles de CSS (c’est déjà le cas pour les variables). Comme le dit Lea, « coder pour un pré-processeur CSS aujourd’hui c’est un peu comme construire un chateau de sable ».
Ceci dit, je n’ai jamais utilisé de pré-processeur CSS. Il est donc possible qu’avec certains d’entre eux, mes craintes ne soient pas justifiées. Pour autant, j’ai énormément de mal à me pencher sur ce sujet et m’y intéresser réellement. Peut-être parce que je suis un vieil intégrateur. Mais peut être aussi parce que j’ai tendance à préférer les choses simples.
Il y a quelques mois, j’étais tombé sur « The MicroPHP Manifesto« , un excellent article dans lequel un développeur PHP revendique son amour pour coder en PHP, sans frameworks. La comparaison donnée dans son introduction est pile poil comme je les aime :
La ligne standard de l’histoire du Punk est qu’il s’agissait d’une réaction aux excès du rock moderne, en particulier le rock progressif de l’époque. La réalité est indéniablement plus compliquée, mais je suspecte qu’il y a en ça une part de vérité. Le rock’n’roll semblait être dans son âge d’or à la fin des années 60s et 70s, inaccessible pour le grand public. Le contraste entre des groupes comme Rush et Black Flag, tous les deux supposés jouer du « rock », était extrême.
Pour rigoler, regardons la batterie du batteur de Rush Neil Peart :
Et maintenant, voici les Black Flag en train de jouer à Los Angeles en 1979 :
Vous pouvez faire tenir la totalité de Black Flag dans l’espace de la batterie de Neil Peart. Et ils joueraient quand même de manière impressionante et déchireraient tout.
Cet exemple colle parfaitement à l’utilisation de pré-processeurs en CSS. Dans l’absolu, CSS est un langage simple à utiliser. Vous n’avez pas besoin d’un compilateur. Vous n’avez pas besoin d’un éditeur particulier. Vous pouvez aller sur n’importe quel ordinateur, coder dans le bloc-notes, et faire des sites « qui déchirent ». Pour moi, une CSS doit être agnostique de tout éditeur et de tout autre langage.
Le manifeste du micro PHP cité ci-dessus s’applique alors parfaitement ici. Et si je devais résumer ma pensée en une phrase, je détournerais le fameux dicton pour donner le manifeste du CSS pur et dur suivant :
Ce qui se passe en CSS, reste en CSS.
STPo, le
Mouaiiiiiiiiiiiiiiiiiiiiiis.
Je suis également un « vieux » et je suis passé à LESS sans difficulté. Et je ne reviendrai jamais en arrière, les avantages sont bien trop précieux au regard des quelques concessions à faire.
Tous les pseudo-arguments que je lis ici relèvent du fanatisme pur et simple, si on suivait tous pareille ligne intégriste sur JS personne n’utiliserait jQuery (ou autre bibliothèque) aujourd’hui… mais tu es sans doute contre également !
Kaelig, le
En effet, pas besoin de préprocesseurs CSS pour faire des sites maintenables et de qualité, ni de jQuery pour manipuler le DOM ou animer un objet.
Dans le principe tu as raison, toute couche d’abstraction est une pollution supplémentaire dans notre faculté à pouvoir éditer ce qui est l’essence de notre métier : le code « pur ». Toutefois, j’aurais aimé avoir l’opportunité de te montrer comment je travaille pour que tu comprennes comment on peut être respectueux de l’optimisation aux petits oignons et en même temps utiliser des outils qui mâchent une partie du boulot (que ce soient des scripts bash, haml ou les préprocesseurs). Ma situation n’est pas généralisable (je suis dans une agence qui a des process spécifiques), c’est pour ça qu’il faut considérer de tels outils au cas par cas (peut-être que dans ton cas effectivement ça ne procurerait aucun gain).
L’important est d’être à l’aise avec ses outils de travail et qu’ils s’insèrent correctement dans une chaine de production maîtrisée. Mais en ayant fait le tour des solutions avant de se ranger dans un camp, c’est tout de même mieux, non ?
PS : merci d’avoir cité mon billet en exemple, j’espère que ça donnera aussi envie à d’autres intégrateurs !
Benoit, le
C’est exactement ce que je pense. Ces outils font perdre plus de temps qu’ils en font gagner au final. Ce sont des gadgets plus « tendances » qu’autre chose.
dew, le
Sincèrement, je ne suis ni pour l’une ou l’autre technique. Il n’y a pas de solution parfaite. Je pense aussi que passer par PHP est un mélange des genres et qu’il faut bien faire attention aux pertes de performance. Cependant, il faut bien comprendre que si on en arrive à ce point c’est qu’il y a un réel besoin.
Si des solutions comme LESS ou SASS montent sur le devant de la scène, c’est qu’il y a des lacunes inhérentes à la gestion des feuilles de styles et à leur rédaction/spécification qui ont été élaborées il y a un certain nombre d’années, avec d’autres contraintes qui ne sont pas les mêmes qu’aujourd’hui.
Il faut penser au-delà de la simple petite feuille classique appliquée à un projet web de dimension moyenne, et prendre en compte que les fichiers CSS ont tendance à gagner en volume avec les sites complexes, il est plus difficile de les maintenir, surtout à plusieurs personnes. Une syntaxe plus concise et hiérarchisée comme LESS facilite la vie et fait gagner du temps.
Ceci a toujours été la vocation des frameworks : faciliter l’appropriation d’opérations plus complexes, faciliter leur écriture pour aller plus loin dans les développements et dans la concision.
Si l’on suit le principe de se limiter uniquement à du « pur et dur », alors jQuery (pourtant exploité sur des millions de sites) ne présente pas d’intérêt par rapport à du beau JavaScript minimaliste. Et de la même façon, en poussant la chose encore plus loin, on pourrait dire que PHP est sur-équipé pour faire du web, que l’on pourrait produire la même chose en HTTP avec du C, voire de l’assembleur. Oui j’ai toujours aimé terminer sur un troll.
Nico, le
Même si je suis l’auteur de « voir pire encore » (et je l’assume sans souci, comme une astuce à utiliser dans certains cas vraiment TRÈS particuliers), je ne suis pas non plus fan des préprocesseurs : en factorisant correctement sa CSS, ses sélecteurs, etc. j’estime pas en avoir le besoin (ce qui ne veut pas dire que l’outil soit mauvais en soi).
Dommage que personne ne se pose la question de QUAND et sur QUEL type de projets/intégrations ils apportent un réel confort et un réel plus… ou pas. A mon sens, c’est plus là que la question est réellement importante, plutôt que de se dire « je vais faire du SASS parce que c’est à la mode ».
Geoffrey, le
Les outils (ou solutions) sont présents car ils répondent à un besoin spécifique dans des cas bien particuliers.
Tout comme l’utilisation de jQuery ou autre bibliothèque, l’utilisation de pré-processeurs CSS ne doit pas être systématique mais doit répondre à un besoin bien spécifique et être une solution réfléchie.
À te lire on a l’impression que leur utilisation est toujours un mauvais choix. Mais ça n’est qu’une impression ;)
PS : belle batterie de Neil Peart !
Thomas, le
Je n’utilises personnellement pas de pré-processor, pour une des raisons ci-dessus : « Tous les membres de l’équipe doivent savoir utiliser cet outil ».
Par contre, je suis d’accord avec Nico. La vraie question est « Dans quels cas il est bon d’utiliser un pré-processor ? ».
Après tout, si ça existe, ce n’est pas pour rien.
Merci pour l’article,
Thomas.
citron, le
Ce n’est pas parce que une chose est inconnue qu’elle est compliquée ou inutile…
Sass possède une courbe d’apprentissage très courte, en moins de deux jours un intégrateur peux être efficace, en moins d’une semaine il est possible de l’utiliser à son plein rendement.
et je suis également un « vieil intégrateur » du siècle dernier.
:)
Pour rejoindre Nico, posez-vous la question « Sur quel type de projets ? ».
Yvain Liechti, le
Ça dépend vraiment du projet. Inutile d’utiliser du less ou autre pour un oneshot de quelque page. Mais dés qu’on parle d’industrialisation ou de charte graphique complète pour un site orienté applicatif là ça prend tout son intérêt.
Exemple d’un bouton full css avec différentes variantes (picto, pas de picto, 2 lignes aligné à gauche, à droite, width 100% ou fixe, une variante rouge et une verte)
Sans Less on aurai des sacré copier collé de codes difficile à maintenir. D’où l’interet de factoriser. Même si au final la css généré est conséquente (pas forcement plus qu’écrite à la main), on y gagne en maintenance.
C’est sûre que ce sera plus agréable quand ces fonctionnalités feront partis de la normes.
Pour l’argument de « tout le monde doit le maitriser » … Intégrateur = métier évolutif
Ce genre d’argument retardent l’arrivée de nouvelles technologies prometteuse.
Erp Derp, le
Les « frameworks » et les surcouches, c’est très bien quand on n’a pas la moindre idée de ce qu’on manipule et qu’on est convaincu qu’on n’aura jamais besoin de connaître parfaitement un langage pour le maîtriser.
Dès qu’on commence à vouloir toucher à des points de détails, on se rend compte que ces usines à gaz vous empêchent de faire ce qu’on veut, et deviennent immédiatement des freins au processus d’intégration.
En clair, si vous débutez vous trouverez ça génialissime (bande de fainéants ! … ou d’ignorants, au choix) mais dès que vous aurez des choses plus sérieuses à faire, vous allez bien galérer.
Pour moi, ça sera « non merci ». Je préfère mon PHP, mon JavaScript et mon CSS sans surcouche.
François "cahnory" Germain, le
Comme le dit un peu tout le monde, tout est une question de besoin/situation/…
Par exemple une utilisation amusante de LESS (bah oui moi je m’amuse d’un rien ^^) et qui ne saute pas forcément aux yeux (car c’est pas non plus un besoin courant) est de limiter la portée d’une feuille de style simplement.
Un petit passage par LESS de ‘#customisable { ‘ . $cssFromUser . ‘}’ et on permet à un utilisateur de fournir du css qui ne s’appliquera qu’à une zone spécifique du document.
Je cite LESS car c’est celui avec lequel je travaille parfois, LessPHP pour être exact.
Pour moi, tant que le pre-processeur fournit un code clair ou, comme tu le dit, proche de ce qu’un humain aurait fait je n’y vois pas de mal. Si jamais l’on souhaite s’en affranchir, il suffira de repartir de la feuille générée et LessPHP remplit bien cette condition à mes yeux. On arrive clairement à « prédire » à quoi ressemblera le code généré à partir du code LESS.
Concernant la résolution des erreurs, si encore une fois le code produit est facilement prévisible il sera facil de retrouver une déclaration dans la source à partir de son équivalent dans le résultat.
Vincent, le
J’aime beaucoup ce petit texte moi (et pourtant ça date) : http://www.pompage.net/traduction/Clarence-le-poney
Ou en bref : mieux vaut être un peu curieux quand même, on ne sait jamais. :)
Rémi, le
Je suis globalement d’accord avec la plupart d’entre vous qu’un pré-processeur doit être utilisé sur des projets bien spécifiques, dans des cas bien particuliers. N’étant pas un petit poney complètement borné, je ferais vraiment l’effort d’essayer SASS sur le prochain projet qui s’y prêtera.
La comparaison avec jQuery citée pas certains d’entre vous n’est à mon avis pas pertinente. L’équivalent d’un pré-processeur CSS en JavaScript serait un pré-processeur JS, comme par exemple CoffeeScript. Et devinez quoi, j’ai exactement les mêmes appréhensions sur CoffeeScript.
Jean-Philippe Encausse, le
Bonjour,
Je suis d’accord avec les arguments « en théorie » mais dans le monde réel c’est vraiment différent:
– 50% des codeurs de CSS ne sont pas webdesigner
– Les webdesigner ne sont pas tous compétents
– 95% des sites web sont des CMS et ne reposent pas sur une page blanche
– Les évolutions CSS ? on va en parler aux gens qui utilisent encore IE6/7 :)
Ainsi on se retrouve très souvent dans ce qui est décrit par la méthode Daisy:
http://romy.tetue.net/methode-daisy
Et c’est à ce moment que LESS prends tout son sens:
– Des variables pour paramétrer le site
– Des mixins qui cachent « les ruses kludges » qui simplifient les concepts
Nous avons décidé de mettre en standard dans notre CMS: LESS et Bootstrap pour simplifier la vie du designer de page web.
Bootstrap va plus loin en proposant un framework CSS qu’il faut « comprendre ». Mais c’est un gain de temps inestimable de ne pas réinventer la roue à chaque fois. Et c’est un tout cohérent. Par contre ça tue le métier de monteur HTML.
Pourquoi LESS et non pas SASS ou Stylus ?
Car la syntaxe LESS est plus proche du langage CSS et donc du métier de WebDesiner. La philosophie est d’améliorer de langage pas d’inventer un nouveau langage pour le front web.
Bartdude, le
Hé bien je suis très content de lire cet article. Dévelopeur m’intéressant à l’intégration, j’ai commencé à lire des trucs sur ces préprocesseurs il y a peu et me demandait quels en étaient les avantages et inconvénients. Si les inconvénient se limitent à ceux cités ici, je prends ! (pour certaints projets évidemment…)
Si je les applique à jQuery :
« – Les pré-processeurs faussent notre perception de la taille finale d’une feuille de style, et ça peut être difficile d’optimiser correctement le tout »
> jQuery cache parfois en 1 ligne une incroyable complexité avec moults tests et boucles. Si les perfs sont effectivement au rendez-vous car il est très bien optimisé, cela fausse également la perception de la taille du code final.
« Les pré-processeurs rendent plus difficile la routine classique de débuggage, où les numéros de lignes visibles dans Firebug (ou équivalent) ne correspondent pas à votre CSS »
> Bon, là, j’ai moins à dire, le debugging JS étant quand-même plus simple je trouve. Cela dit, une erreur par-ci ou par-là dans le code JS renvoie parfois à une ligne dans le core de jQuery, pas vraiment utile donc comme erreur.
« L’utilisation de pré-processeurs en équipe nécessite que toute l’équipe maîtrise l’outil »
> C’est valable pour tous les outils… y compris jQuery ! Si on considère ca comme un handicap, toute nouvelle technologie est bannie d’une équipe déjà établie et tout le monde en reste à faire ce qu’il sait. C’est d’autant moins un problème que la courbe d’aprentissage est courte bien sûr.
« Les fonctionnalités apportées par les pré-processeurs finiront par arriver dans les spécifications officielles de CSS (c’est déjà le cas pour les variables). Comme le dit Lea, « coder pour un pré-processeur CSS aujourd’hui c’est un peu comme construire un chateau de sable ». »
> Quand j’ai un truc à faire en jQuery, je n’attends pas qu’un plug-in sorte ou que jQuery l’intègre dans une release, j’y vais et tant pis si mes trucs sont dépassés ensuite car quelqu’un a développé un truc mieux et plus pratique.
Bref, ca n’a quand-même pas l’air si mal ces préprocesseurs, même si j’ai conscience que c’est le dévelopeur qui parle.
Cela dit, une question vraiment innocente et tant pis si elle est stupide : peut-on réellement s’en passer si l’on souhaite réaliser un responsive design ?
Oléo, le
Pas vraiment d’accord avec le commentaire de Erp Derp. Les préprocesseurs comme sass ou less prennent tout leur sens quand on maîtrise déjà bien css justement. Ensuite on ne peut pas dire qu’ils « nous empêchent de faire ce qu’on veut » puisqu’ils sont complètement compatibles avec la syntaxe css… De mon côté, ça me fait juste gagner énormément de temps de développement et de maintenance.
Mais je crois qu’il n’y a pas de bon choix, à chacun ses outils et ses préférences. Cela dit je pense que beaucoup de gens qui critiquent n’ont pas essayé, et c’est bien dommage pour eux :)
sacripant, le
Je partage un peu cette vision sur l’utilisation des préprocesseurs.
Moi j’essaye d’utiliser au maximum les principes d’oocss : utiliser les class multiples.
Une fois cette logique comprise et mise en pratique, les mixins et le principe de l’héritage des Preprocesseurs ne servent plus à rien.
Il reste les variables, intéressant, mais un bête rechercher/remplacer fait souvent l’affaire; et les calculs (c’est vrai que de pouvoir mettre en variable la valeur typo line-height et utiliser les calcul pour aligner automatiquement les bloc sur une grille vertical, c’est quand même super pratique). calc() fonctionne dejà dans quelques navigateurs et les variables sont en brouillon au W3C.
Néanmoins ces outils permettent une réflexion sur comment rendre plus efficace l’écriture CSS . Et cela sera certainement bénéfique à ce langage.
piouPiouM, le
Le langage CSS est simple, il est vrai. Malheureusement les différentes implémentations et l’inertie rencontrée pour qu’une évolution du langage soit validée est telle que CSS est devenu l’un des pire langage à utiliser. Je fais de l’intégration depuis des années et, franchement, j’en ai ma claque de devoir écrire des hacks dans tous les sens et retenir 50 variantes d’une même propriété pour que mon intégration soit visible sur tous les navigateurs du marché (oui, parce que dans la vrai vie nous devons supporter IE 7++ et Firefox 3.6++ *sniff*).
Un pré-processeur comme Sass, accompagné de son framework CSS3 Compass me permet de me concentrer sur l’intégration et non sur les gymnastiques de compatibilité. Je gagne ainsi un temps incroyable.
En tant qu’utilisateur d’un pré-processeur je vais reprendre ici les points évoqués par Lea Verou :
1. « Les pré-processeurs faussent notre perception de la taille finale d’une feuille de style, et ça peut être difficile d’optimiser correctement le tout »
Et ? Si vous travaillez correctement vous aurez toujours un ordre d’idée de la taille finale de votre CSS, même en utilisant un pré-processeur.
Vous pensez aux performances ? Même 19Ko de CSS est rapidement interprété si la feuille de style évite de coller des sélecteurs * et enfant à tout va. Généralement si problème de performance il y a, jetez plutôt un coup d’œil à la construction de votre page, votre JS et à la manière dont vous délivrez vos assets.
2. « Les pré-processeurs rendent plus difficile la routine classique de débuggage, où les numéros de lignes visibles dans Firebug (ou équivalent) ne correspondent pas à votre CSS »
Oui. Deux écoles dans ce cas :
– en utilisant Sass, une extension Firefox (FireSass) est disponible pour avoir la remontée des fichiers sources dans votre inspecteur Firebug.
– vous connaissez votre travail, vous êtes sensé vous repérer dans vos sources.
3. « L’utilisation de pré-processeurs en équipe nécessite que toute l’équipe maîtrise l’outil »
Il s’agit à mon sens du seul vrai contre-argument. Effectivement, il faut que l’équipe monte en compétence sur l’outil. Mais l’argument peut-être nuancé : Sass et surtout sa syntaxe SCSS héritent directement de CSS. Cela implique que tout collaborateur peut travailler directement en CSS sur le projet.
Notez que la montée en compétence est rapide. Ayant amené plusieurs personnes à travailler avec de SCSS/Compass je vous assure que cela s’est fait sans heurt.
4. « Les fonctionnalités apportées par les pré-processeurs finiront par arriver dans les spécifications officielles de CSS (c’est déjà le cas pour les variables). Comme le dit Lea, « coder pour un pré-processeur CSS aujourd’hui c’est un peu comme construire un chateau de sable ». »
Le problème étant le temps employer pour conjuguer la remarque. Dans combien d’années ? Pendant combien d’années allons-nous encore devoir mémoriser/ajouter les diverses syntaxes navigateurs ? Alors que les maquettes intègrent de plus en plus de notions CSS3, un pré-processeur vous aidera à les implémenter plus vite.
Une avant-dernière remarque (ouf :]) : la compilation côté serveur est une mauvaise pratique. Elle devrait se faire au niveau du poste des intégrateurs qui poussent la version compilée (la feuille n’évoluant pas tous les 4 matins). Alors oui, cela demande de savoir travailler en équipe et de versionner un projet, mais on évite de publier n’importe quoi sur le site.
Pour finir, la taille du projet est évidemment un argument à prendre en compte lors du choix de ses outils. Travaillant régulièrement sur des projets de 3-12 mois à quasi temps plein, le couple Sass/Compass m’a permit d’organiser mes projet de manière intelligible et de permettre à des collègues non-intégrateurs d’intervenir sur les projets sans pour autant produire des feuilles de styles de 30000 lignes (vous savez, chacun collant ses modifs à la fin de la feuille). Un gros plus.