out through the winter throat

out through the winter throat le blog de Anahkiasen.

Workflow I : Les préprocesseurs (LESS, SASS, CoffeeScript, HAML etc)

Depuis quelques temps j’ai envie d’écrire une mince série de billets sur ce que je fais plus concrètement au travail. Histoire de partager, recueillir quelques avis et puis pouvoir discuter un peu de sujets qui me passionnent avec des gens qui traversent la même chose. Comme je l’avais mentionné dans un précédent article, j’ai commencé à travailler il y a deux ans et demi de cela. Quand je suis arrivé, j’avais quelques vagues et lointaines connaissances de PHP, des connaissances un peu plus récentes en CSS3 et xHTML, et puis c’était environ tout.
Projection aujourd’hui, où j’ai peu à peu monté et amélioré mon propre framework PHP avec tout le confort et la simplicité dont j’ai besoin; où j’ai la tête plongée dans le CSS3 et le HTML5, ses normes et avancées quotidiennes en termes d’interface et d’ergonomie. Je tâte un peu de Javascript et d’AJAX. Je suis quelques blogs, me tiens au courant des dernières modes et nouveautés, participe activement au développement des projets qui me sont chers sur Github, etc. Sans jamais vraiment arriver à m’appeler webdevelopper, j’ai parcouru bien du chemin et tiens beaucoup mieux le rythme face au flux perpétuel de changements d’un web qui se renouvelle en permanence.

Je comptais diviser ces articles en quelques points, un peu au hasard. Aujourd’hui, et parce que c’est ce qui me passionne le plus en ce moment, je voulais aborder un peu le monde des préprocesseurs qui ont le vent en poupe depuis quelques mois*. Ils existent depuis plus longtemps certes, mais j’ai l’impression que c’est vraiment depuis peu qu’ils ont explosé et se sont démocratisés.
Qu’est-ce qu’un préprocesseur ? C’est comme son nom l’indique une sorte de langage supplémentaire dans lequel on va coder, et qui va ensuite être processé (compilé quoi) vers un autre langage. L’intérêt d’employer des préprocesseurs CSS, JS ou HTML ? C’est qu’ils rajoutent des couches assez exceptionnelles de fonctionnalités, d’améliorations de syntaxe et de possibilités, à des langages vieillissants. Ils simplifient des tâches répétitives, sont plus souples, et l’intérêt comme ils sont ensuite compilés et non calculés en direct, c’est que le client ne voit aucune différence.

* Ma copine me précisant que cette expression lui fait penser à « PD comme un foc », à cause du vent en croupe.

LESS, SASS et Compass

sass
696863337

Petite note préambule : je n’aborde pas les autres préprocesseurs car moins connus et ou plus mis à jours (Stylus etc).
LESS et SASS sont tous les deux des préprocesseurs CSS, qui à mes yeux de tous les langages était celui le plus vieillissant. Comme l’abordait Chris Eppstein, le créateur de Compass, le CSS est devenu un langage qui ne répond plus aux attentes et besoins du web moderne. Beaucoup de choses ont contribué à l’alourdissement de ce langage : son interprétation variable selon les navigateurs, sa syntaxe trop simpliste, les différents moteurs qui l’empoisonnent de propriétés propriétaires et contribuent à sa non-uniformisation. Entrent en jeu les préprocesseurs, ici LESS, SASS. Tous différents mais se rejoignant sur un ensemble de grands thèmes : la création de fonctions (ou mixins), des bouts de CSS dynamiques qu’on peut pré-créer et réemployer, l’ajout de variables au CSS, de fonctions permettant le calcul de mesures et de couleurs, et le nesting de classes. Ce n’est pas tout bien sûr mais c’est l’essentiel. De là découlent énormément de possibilités.


À gauche du SASS, à droite le résultat en CSS

À l’idée d’aborder ce paragraphe j’étais teinté d’une légère honte en ayant l’impression de retourner ma veste. Deux articles plus bas j’encensais LESS par sa simplicité d’intégration et ses possibilités, et à contrario descendait le SASS par sa difficulté pour le premier venu. LESS pouvant être compilé à la volée via du Javascript, et SASS devant être compilé via Ruby, à l’ancienne dans la ligne de commande (sauf si votre projet est lui aussi en Ruby, par exemple via Ruby on Rails).
Mon changement d’opinion s’est fait alors que je tentais de transposer un fichier SASS en LESS; alors que tout se passait plus ou moins bien, je ne cessais de buter sur des fonctions et choses diverses complètement irréalisables en LESS. Pour une raison simple : SASS possède des syntaxes de boucles et de conditions (if, for, while, else etc) que le développeur de LESS refuse d’intégrer par principe. J’ai alors peu à peu entamé ma migration vers le SASS et quand j’ai mis la pointe du pied dans l’océan de possibilités qu’offrait Compass, je n’ai plus regardé derrière moi.
Compass est une librairie de fonctions pré-créées en SASS, une sorte de toolkit prévoyant tout ce qu’on peut imaginer avoir besoin pour faire du CSS de nos jours. Création de sprites à la volée, gestion dynamique des dossiers, myriades de fonctions et mixins, grille CSS, et j’en passe. Je me suis peu à peu rendu compte en codant en SASS des limitations du LESS et ai compris que le seul vrai point noir de ce langage était sa documentation déroutante et peu aguichante pour le nouveau venu alors que LESS propose un site simple en une page. Un point que le développeur assure être en train de corriger via une équipe dédiée à la refonte du site et de la documentation de SASS.

Le poids le plus important à mon goût c’est que Twitter lors de la création de Bootstrap, son framework CSS, a décidé de le coder en LESS. J’ai mis un peu de temps à faire la transition, moi qui suit le projet aux derniers commits, mais après création d’un petit script de conversion LESS->SASS ça ne me pose plus de problèmes.

CoffeScript

267-coffeescript-basics

Au niveau du Javascript je passe désormais toujours par du CoffeeScript. D’une parce qu’il m’évite des erreurs de débutants, moi qui n’emploie pas autant le Javascript que d’autres langages, et de deux parce qu’il simplifie sa syntaxe à un point que je n’imaginais possible. Les exemples en page d’accueil sont à mes yeux les plus probants donc je vous laisse y jeter un oeil.
De paire avec des bibliothèques comme jQuery c’est désormais un plaisir d’apporter interactivité et dynamisme à des pages plates, et je n’ai à ce jour rien trouvé que sans grandes connaissances en JS je ne puisse faire à l’aide de ces deux outils.

HAML

haml

HAML est un préprocesseur HTML. J’en parlerai moins parce que de tous c’est celui que j’emploie le moins, la plupart de ce dont j’ai besoin pouvant déjà être fait en PHP. Il reste cependant utile lors de la création de longues pages HTML complexes (emailing etc), car il simplifie énormément la syntaxe HTML, un peu à la manière de ZenCode.
Il est aussi assez peu mis à jour, le créateur étant celui de SASS et étant du coup assez accaparé par ce dernier. On retrouve une syntaxe justement proche du SASS, avec des { } qui sont omis au profit de l’indentation, et une intégration du Ruby assez soutenue. La possibilité d’y dédier des zones “filtres” où l’on peut par exemple employer du Markdown ou autre, rend la mis en page de contenu très simple et ça reste un bon gain de temps par rapport au fait de taper le HTML à la main. C’est aussi beaucoup plus facile de revenir dessus pour corriger des choses.

Conclusion

Cet article était plus dédié à ceux qui ne connaissent pas la chose qu’aux autres. En tout cas dans mon travail à l’heure actuelle ce sont désormais des outils dont je pourrais pas me passer. Revenir au simple CSS maintenant, avec toutes ses contraintes et ses lourdeurs, me serait impossible.
Pour ceux qui ont du mal ou manquent de courage quant à se lancer dans Node.js, compiler à la console et autres, je suis prêt à vous guider si vous le voulez. Ce ne sont pas les tutoriaux qui manquent mais étant moi-même passé par là je sais à quel point il est dur d’entrer dans le monde du Ruby, des gems et compagnie quand on n’a jamais touché à autre que du PHP.

Tags: , , , , , , ,

14 commentaires pour “Workflow I : Les préprocesseurs (LESS, SASS, CoffeeScript, HAML etc)”

  1. PinGoo dit :

    Je ne comprend pas le fait d’utiliser ces technologies alors qu’avec un bon bootstrap (un pack fait maison qui a fait ses preuves en production et qui est une bonne base pour démarrer un projet de tout type) tu arrive au même résultat.
    Je pense que cela peut valoir le coup quand tu dois créer des sites rapidement et à la chaine.
    Dans mon boulot nous avons des clients historiques (+10 ans) et ils recherchent la qualité, la performance, etc… Les CSS peuvent aujourd’hui être utilisées à plein potentiel en production (die in hell IE6 !). Moi qui travail avec de grosses feuilles de style, je peut t’assurer que le fait de devoir compiler ma CSS à chaque upload me ferait péter un plomb.

  2. Anahkiasen dit :

    Ça ne change rien à la structure que tu adoptes dans tes fichiers, ça change la facilité et les possibilités quand tu fais des modifications. Mon framework comprend une CSS de base et d’autres réservées à certains plugins, j’ai les fichiers sass dans un dossier et les fichier css précompilés dans un autre.

    La perte de temps est vraiment nulle : les compileurs tournent en tâche de fond, tu les lances sur un dossier, et ensuite dès que tu fais une modification sur un fichier sass, less ou coffeescript, etc. ils recompilent discrètement. Pour peu que ton IDE gère la synchronisation avec un FTP, pour que ça envoit les fichiers css/js/etc dès qu’ils sont modifiés, je ne vois pas ce que ça change.

    Et justement si tu travailles sur de grosses feuilles de style ces langages devraient t’apporter une aide incomensurable.

  3. darkalex dit :

    En plus d’avoir un watch et interprétation du fichier à la volée il est agréable de mettre un plugin comme livereload qui permet de rafraîchir la page automatiquement. http://livereload.com/ (Disponible en plugin aussi).

    Pour en revenir à PinGoo si tu bosses avec de grosses feuilles t’as pas l’impression de te répéter sur certaines portions de codes ou d’écrire 10fois le même code pour webkit, moz etc.. ? Tout ça c’est vite oublié quand tu commence avec Compass ou Less

  4. PinGoo dit :

    Je bosse en CSS full classe et je peut t’assurer que je ne vois pas comment cela pourrait m’aider. Si j’ai à modifier un code couleur, un simple rechercher/remplacer fera l’affaire. On en discute pas mal au boulot et on ne voit pas du tout ce que cela pourrai nous apporter de plus.

  5. Anahkiasen dit :

    J’ajoute qu’en terme de Bootstrap, il est justement d’autant plus utile d’employer le pouvoir des prépocesseurs pour créer une feuille de bootstrap dynamique que tu peux ensuite adapter à chaque site juste en modifiant quelques variables. Jette un œil justement à la page de Twitter Bootstrap et la manière dont ils emploient les variables pour créer un design presque prêt à employer.

    Enfin, passer du CSS aux préprocesseurs est on ne peut plus aisé. SASS intègre des outils de conversions très fonctionnels, de même pour HAML et CoffeeScript. D’autant plus que le SASS se divise en deux syntaxes, le SASS pur comme vu sur l’image de l’article, et le SCSS qui a exactement la même syntaxe que le CSS. En un sens donc, toute feuille de CSS peut être une feuille de SCSS qui ne demande qu’à être enrichie. cf. le site officiel.

  6. Radical dit :

    Je suis assez mitigé à propos des préprocesseurs. J’utilise pas mal Zencode au travers du plugin Sublime pour faire une sorte d’auto complétion HTML mais je me verrais pas avoir des fichiers en ZenCode, tout comme je me verrais bien coder en Coffee mais pas du tout en commiter.

    Ce sont de très bon outils pour développer vite, de productivité, mais pas le format final souhaitable.

    Mais c’est un avis très peaceful et je comprends tout à fait ton point de vue.

    Note : tu parle de {} remplacés par l’indentation à propose de HAML, j’imagine que tu penses plutôt aux chevrons '< '>‘ ?

  7. Anahkiasen dit :

    Les langages comme le SASS sont au CSS ce que le PHP est au HTML; certes tu peux faire un rechercher/remplacer sur toutes tes pages HTML mais j’ai du mal à saisir comment tu arrives au final à un gain de temps par rapport au fait de changer une variable à un endroit ?

    Je veux dire avec les possibilités de ces langages et de leurs fonctions de couleurs et contraste telles darken/lighten/saturate/desaturate/mix/fade, tu peux changer toute la teinte chromatique d’un site simplement en changeant trois caractères. J’ai du mal à comprendre comment vous tempérez de telles avancées ? D’autant que comme je l’ai dit, même si tout est compilé pendant que vous travaillez, ce qui en ressort reste du HTML/JS/CSS, ce n’est pas plus dangereux ou instable qu’avant, le format final est le même, je vois mal ce que vous voulez dire.
    En particulier pour PinGoo ; je veux dire même avec la feuille CSS la plus préparée du monde à toutes les situations, ou à moins que ce soit un genre d’OOCSS, tout ce que dans ma tête tu as au final c’est une grosse feuille CSS lourde à inclure plutôt qu’une petite feuille CSS flexible qui ne contient que ce dont tu as besoin pour chaque site avec le dynamisme du SASS.

    Franchement je vous conseille de faire un tour dans la doc de Compass voir tout ce qui est offert, de jeter un œil aux sources, aux variables de configurations possibles, à la manière dont ça gère et vérifie les ressources (images etc). Pour moi c’est passer à côté d’une puissance énorme en voulant rester sur ses plates bandes.

    Après je comprends, on est dans un web où tous les deux jours quelqu’un réinvente la roue, et il est toujours difficile de voir l’intérêt de se lancer dans un truc comme ça par rapport au travail d’adaptation que ça demande en se disant que le gain final ne le vaut peut-être pas. Mais pour avoir fait le pas pour ma part je considère le gain énorme. Je vous critique pas ou j’essaye pas de faire du forcing, c’est juste que j’ai du mal à voir comment on peut dire qu’au final on y perdrait du temps. Après je veux dire chacun à son système de travail et c’est normal que changer ses habitudes ça paraît toujours un peu stupide.

    Moi c’est juste que j’ai toujours eu le mécanisme de m’éviter toute tâche répétitive. J’ai toujours codé dans cette optique, et par amour du défi. J’ai toujours aimer coder, dans tout langage, et je crois que c’est une tare propre à nombre de développeurs que de passer plus de temps à coder des outils pour éviter de faire la même chose plutôt que de simplement refaire ces choses.

    @Radical, oui je voulais dire chevrons, désolé pour l’erreur.

  8. PinGoo dit :

    Je ne remet pas en question ton article, et depuis toujours je respect ceux qui partagent comme tu le fait. Mes messages sont justes des interrogations. Comme je l’ai dis plus haut, je ne comprend pas pourquoi passer par des langages/des syntaxes qui au final seront compilés pour donner autre chose. Pourquoi ne pas simplement apprendre à maîtriser le HTML, le CSS et surtout le Javascript. Le pire étant pour moi Coffescript ! Je me vois mal apprendre une syntaxe pour qu’au final cela devienne du javascript (qui fonctionne certes, mais qui ne sera jamais mieux qu’un dev direct dans ce langage).
    Pour finir je le répète. Dans des projets rapides, pas trop gros et où l’optimisation n’est pas le point central, pourquoi pas !

  9. Anahkiasen dit :

    Attention à l’amalgame : coder en SASS ne veut pas dire qu’on ne sait pas coder en CSS. Le SASS _est_ du CSS, enrichi certes mais il en reste. Et même si dans mon exemple j’avoue avoir des difficultés avec le JS, j’ai depuis longtemps eu le temps d’apprendre à maîtrise le CSS tout comme le HTML.
    Et le code n’en sera pas moins optimisé; ce n’est ni SASS ni CSS qui font l’optimisation, c’est le développeur. Je te redirige vers cet article qui parle un peu des reproches qu’on fait souvent à SASS, intitulé SASS doesn’t create bad code, bad coders do .

    Quant au CoffeeScript c’est sensiblement la même chose, j’utilise langage par rapidité de formule mais le CoffeeScript n’est que du Javascript enrichi. Tu peux taper du Javascript pur dans une feuille CS, tout ce qui change c’est que tu as une poignée de nouvelles syntaxes en plus qui raccourcissent d’anciennes syntaxes lourdes et mal pensées. Du coup plutôt que d’apprendre à faire quelque chose en vingt lignes tu le fais en deux.

  10. Mousse dit :

    PinGoo: tu me fais penser à certain développeurs avec qui je travail. Ils se braquent, n’en veulent pas et hurle sur tout les toits que ça ne permet pas une bonne optimisation du CSS, que c’est lents, ça n’apporte rien..

    Si c’était vraiment le cas, je me serrais pas fais chier à mettre en place tout un tas de proccess avec des déploiments/compilation/compression automatique avec Ant.

    Less/Sass/Compass/Turbine… (y’en à des tonnes) permettent, justement, de mieux penser tes CSS, de les simplifiés et de les rendre plus lisible. Avoir une CSS de 800 ligne avec chaque ligne étant une instruction, j’en peux plus, c’est une perte de temps. Avoir 10 fichier, normalisé, nommé et structuré, c’est du temps de gagné en prod et en debug. Il ne t’apportent rien de plus que des petites fonction qui te simplifie la vie (faire un mixin, un include…) mais NE SURCOUCHE PAS LE CSS !

    Et comme dit Anahkiasen (putain, je déteste toujours autant ton pseudo, Man6.) c’est ton boulot de faire du code propre et optimisé. Pas au prépro.

  11. PinGoo dit :

    Je ne suis donc pas le seul à penser cela alors, tu me rassure. Je t’invite aussi à me relire car je pense que tu as mal interprété mes propos.

  12. Mousse dit :

    J’ai très bien compris le sens de ton raisonnement mais je pense que je me suis peut être emporté en écrivant ses lignes (j’ai 2 devs sur les bras qui ne veulent pas qu’on parle de Framework…)

    En gros, pour moi, Less/Scss/Whatever m’apporte un gain de temps considérable en debug : je sais que tel élément est dans tel fichier et fait appel à telle fonction. C’est donc cette fonction qui déconne. (je n’utilisa pas la syntaxe Sass, qui resemble moins au CSS). De plus, associé à Apache Ant et quelques autres éléments, tu peux facilement déployer ce genre de solution sur tout tes projets.

    Au final, tu te retrouve un peux dans l’optique d’un framework : tel élément bug -> ça viens de tel élément.

    Par contre, pour CoffeeScript/Dart, c’est plus complèxe : la syntaxe n’étant pas la même entre le code source et le code compilé, faire du débug est bien plus lourd et long (perso, j’ai du mal à accroché, je préfère utiliser un framework comme ExtJS, Backbone…)

  13. moechofe dit :

    Pour avoir testé SASS sur une équipe de 20 personnes, non seulement c’est un merdier pour mettre en place, mais en plus il faut aue les 20 personnes sachent s’en servir. Et le mises en production peuvent devenir douloureuse surtout lorsqu’on utilise des CDN.
    Peut-être que ces outils sont parfait pour de petites équipes.

    Petite note concernant les fonctions darken/lighten/saturate/desaturate/mix/fade : ça ne s’applique pas aux images. Or, dans certain cas, le design est un astucieux mélange de CSS et de PNG, car c’est souvent le meilleur moyen d’obtenir les meilleurs performances.

    Article intéressant.

  14. Anahkiasen dit :

    Pour l’application à grandes échelles c’est effectivement autre chose. Il faut installer SASS (et Compass facultativement) sur chaque poste, à moins qu’il y ai moyen via console d’installer sur chaque poste du réseau.
    Pour le CDN je ne comprends pas trop par contre ? Encore une fois, le code compilé est du CSS, qui ne requiert rien d’autre pour tourner sur le serveur qu’un navigateur. LESS permet effectivement de compiler le .less en temps réel via du Javascript mais bon pour moi c’est plus utile en développement qu’en production, je ne me verrais pas laisser le hasard d’une erreur ou d’une panne du script .less faire tomber toutes mes feuilles CSS.

    Après pour le temps d’apprentissage, j’ai envie de dire c’est comme tout ajout au workflow de n’importe quelle équipe, faut bien que tout le monde se mette au niveau, c’est pas propre aux préprocesseurs. C’est sûr que travaillant seul c’est pour moi moins contraignant de faire des modifications à ma manière de travailler ou au moteur de mes sites.

    Rien à voir mais je suis tombé sur ça aujourd’hui, ça m’a pas mal fait marrer, pour rester dans le sujet : moreCSS.

Laisser un commentaire

Si vous avez un compte sur WeFrag, connectez-vous pour publier un commentaire.

Vous pouvez, entre autres, utiliser les tags XHTML suivant :
<a href="" title="">...</a>,<b>...</b>,<blockquote cite="">...</blockquote>,<code>...</code>,<i>...</i>