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.

LESS, SASS et Compass

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.

À 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

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 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.