Pourquoi j’ai installé et supprimé Less en moins de 24 heures

Flattr this!

Salut les kids ! Aujourd'hui je vais vous parler de ma désagréable expérience avec Less. Un billet de blog qui fera bien plaisir à mon ami goldoraf qui s'est quelque peu démené pour m'éviter cette mésaventure. J'aurais dû l'écouter.

Less

Je vais quand même commencer par présenter l'animal. Nous avons affaire à un package node qui permet de compiler des fichiers éponymes en fichiers CSS et pourquoi pas au passage de les compresser. C'est à dire d'en réduire la taille sur le principe simplifié de la minification pour le JavaScript. Ne sont supprimés que les espaces et autres commentaires.

Sur le principe, l'idée est excellente mais.

Les énormes défauts

Il n'y a que peu ou pas d'option. La plus expliquée mais la moins importante est de pouvoir activer la compression avec l'outil développé par Yahoo plutôt qu'avec la compression native. Peut-être très utile mais bon, pour lé néophyte que je suis, je ne vois pas l'intérêt à part que le nom de Yahoo m'inspire plus confiance que le fait que je ne sais même pas qui a développé cette partie de Less. Avantage donné empiriquement à Yahoo pour le simple fait qu'on peut suspecter qu'ils ont de bons ingénieurs et qu'ils ont été plusieurs à plancher là dessus. Je l'ai dit, c'est parfaitement empirique, donc arbitraire, même si encore une fois, je ne vois pas ce que ça change.

En voulant aussi compresser aussi des fichiers CSS externes à mon code, j'ai rencontré un autre os. Quand on est en présence de hacks basés sur les commentaires pour assurer la dégradation élégante pour les vieux navigateurs, il crache une syntax error et refuse donc logiquement de faire le travail attendu. Pas de "je laisse tomber cette instruction pour passer à la suite", c'est directement une erreur fatale et salut la compagnie.

Autre souci, les expressions. Il y a tout un tas de cas où on utilise des expressions pour calculer une propriété. Là aussi, il sort une syntax error.

L'un comme l'autre peuvent être protégés par un hack supplémentaire indiquant à Less de prendre tel quel une chaîne sans chercher à l'interpréter. M'enfin si je suis obligé de protéger moi même ce que je veux compresser plutôt que de laisser faire un programme qui pour moi devrait le faire, c'est mal parti.

Pas convaincu de la méthode et surtout pas pratique du tout.

Petit point positif tout de même

C'est un des rares packages node que j'ai réussi à installer sur une Debian sans galérer. Johnny-five a beaucoup résisté et Yeoman a été une vraie misère jusqu'à ce que je tombe sur une procédure viable.

(Faudra m'expliquer comment on peut arriver à produire un package node pas "facilement" installable sur linux et facilement sur Mac. L'amère impression de revenir aux premières conneries faites avec Java)

Conclusion

Je vais donc m'empresser de basculer sous Sass, espérant y trouver un outil plus fiable et malléable que Less.

Bonus d'XP !

Eivdement, tout cela n'était que mon avis perso. Je vous propose donc :

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans CSS, avec comme mot(s)-clef(s) , , , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • http://atnos.com brunto

    Sass + Compass c’est quand même bien plus pratique et fonctionnel faut pas en abuser non plus.

    • http://www.mathieurobin.com/ Mathieu

      Ça tombe bien, c’est ma prochaine étape 😉

  • Cyrille P

    Juste pour savoir : c’est le package node que tu n’aimes absolument pas, ou Less dans sa totalité? Tu ne remets pas en cause le principe en lui même?

    Merci !

    • http://www.mathieurobin.com/ Mathieu

      Salut! Alors non, je ne rejette pas le principe. Je dirais même que le principe est génial. C’est surtout le compilateur LESS qui me rend fou. Je ne comprends pas pourquoi on ne peut pas lui dire de faire de la reprise sur erreur. Une erreur de syntaxe dans une feuille CSS n’aura jamais d’impact ‘fatal’ ou ‘critique’ sur l’exécution d’un script ou l’affichage d’un site. Ça peut cacher des trucs, casser l’apparence du site mais un simple warning à la compilation suffit. Un tel extrémisme dans les règles de syntaxe à la compilation ne devrait être appliqué que sur du « vrai » script. J’entends vrai, dans le sens où c’est quelque chose qui amène de la logique comportementale.

  • http://log.winsos.net CrEv

    Pour commencer, j’utilise très rarement less, mais pour tout un tas d’autres raisons / mylife

    Il n’y a que peu ou pas d’option

    Et ? Quelles options tu souhaiterais, quelles options te manquent ? Le fait de ne pas avoir d’option n’est pas en tant que tel un problème. Ce qui est problématique c’est si il t’en manque une.

    Le reste n’est finalement que la tentative d’utiliser less à partir de fichiers existants pleins de hack ou de choses non standards (expressions). C’est pas tellement le but de less ça.

    As-tu tout de même essayé less pour ce qu’il est, c’est à dire un pré processeur css et non un minifieur / compresseur de css ?

  • Nico

    Je ne suis pas d’accord avec toi, du moins pas en totalité! On utilise less ici, et ca nous arrange grandement de disposer du système de mixins! Pour les soucis de compilation, nous n’en avons jamais eu, aurais tu des exemples?
    Un des énormes avantages que nous trouvons à less est d’être géré en natif via assetic, qui fonctionne très bien de paire avec twig! Si je devais balancer un super combo gagnant, ce serait twig + assetic + less, et la tu obtient la possibilité de compresser ton less avec ce que tu veux. Pour la compilation, node le fait fort bien comme dit précédemment, mais je crois qu’il existe des outils php qui le font aussi – moins bien j’imagine, de façon totalement empirique -.

    • http://www.mathieurobin.com/ Mathieu

      Exemple simple, essaie de compiler/compresser les CSS de jQuery UI. Il y a des hacks pour la compatibilité IE 6 (http://www.mathieurobin.com/2012/12/pourquoi-continuer-de-supporter-ie-6/), ceux-ci provoquent une « syntax error » à la compilation Less. Il faut systématiquement remettre la main dans le code pour les échapper. Sauf que toucher au code d’une librairie, c’est pas génial. Ne serait-ce que pour une question de maintenance. Alors apparemment, pour les échappements, c’est le même problème chez Sass ceci dit. Je trouve dommage voire carrément prohibitif le fait qu’il n’y ait donc pas de reprise sur erreur possible pour dire « bah tant pis, cette zone là me semble foireuse », j’y touche pas et je passe à la suite. Il y a des cas où ça n’est pas possible. Mais sur une expression, il est facile de l’isoler et passer à la suite…

  • Robin

    En ce qui concerne les hacks IE, je n’ai pas de soucis de mon côté en utilisant CodeKit (les CSS de jQuery UI passent sans problèmes). Du coup, je pense qu’il faudrait parler d’ outil permettant de compiler les fichiers Less plutôt que du langage en lui même étant donné que l’implémentation ne doit pas être la même dans chacun de ces outils.

    Après, la compression n’a rien à voir avec LESS : c’est une fonctionnalité proposée par l’outil. D’ailleurs, le compresseur de Yahoo peut très bien être utilisé seul.

    Bref, LESS n’est pas un compilateur, mais un langage, et c’est l’implémentation de ce langage dans les différents compilateurs qui peut se retrouver perdue face à une expression un peu exotique (comme un hack IE) :)

    • http://www.mathieurobin.com/ Mathieu

      D’accord, il est vrai que du coup, mon problème pourrait être résolu en utilisant un autre outil dédié à Less. A suivre donc, mais ça m’étonnerait qu’on choisisse autre chose qu’un package node. En fait, il nous faut surtout un outil en ligne de commande fonctionnant sur Debian. Donc on oublie CodeKit, qui ne tourne que sur Mac (rien que pour ça déjà, j’éjecte, mais c’est mon avis perso).

      • http://elliptips.info Robin

        J’ai essayé pas mal d’outils et je dois dire que je ne pourrais plus me passer de CodeKit. Il suffit d’y glisser son projet et l’application s’occupe toute seule de compiler et compresser les CSS (LESS ou Sass), d’optimiser les images (JPEG et PNG), de vérifier et compiler les JS (JSLint/JSHInt et CoffeeScript), le tout à chaque enregistrement du fichier de source visé tout en injectant directement les changements dans le navigateur. J’ai déjà cherché une solution identique sous Windows et Linux que j’utilise aussi, mais n’ai jamais vraiment trouver d’alternative.

        De toute façon, à chacun sa technique, l’important étant de gagner du temps :) Par contre, j’avoue ne pas comprendre l’intérêt de compiler les CSS sur le serveur (en PHP) ou côté client en JavaScript, car cela demande de modifier le code ou ajoute du traitement inutile alors qu’il suffit de le faire une fois avant de déployer son site/application.

        • http://www.mathieurobin.com/ Mathieu

          Parce qu’on a un peu plus de 300 sites et donc qu’on a industrialisé toutes les méthodes, tous les procédés et qu’on gère tout via un backoffice unique ou nos IDE. Par contre, oui, coté client, strictement aucun intérêt.

          Du même coup, le LiveReload est inutile chez nous parce que du coup inefficace.

          • http://elliptips.info Robin

            Arf je ne suis pas sûr de bien comprendre le problème. Imaginons qu’une mise à jour du CSS (donc des fichiers LESS) soit faite sur l’un des sites par l’intégrateur. La modification est ensuite déployée sur vos serveurs et c’est à ce moment-là que tu souhaites compiler les fichiers LESS en CSS si j’ai bien compris ? Maintenant, si l’intégrateur utilise un outil pour compiler directement ses modifications et les inclure dans le VCS (un truc transparent directement dans son IDE), il n’y aura donc pas de routine à mettre en place sur les serveurs puisque le fichier CSS généré sera déjà le bon au moment du déploiement non ?

  • http://www.pure-tentation.fr syndrael

    Hélas pas trop le temps de lire vos comm’ qui doivent être axés Sass + Compass.. mais moi j’utilise PHPLess et ça marche bien…sauf les exceptions qui pourraient être gérées dans le futur.
    S.

  • Mathieu

    Tu rencontreras les mêmes problèmes avec sass. Pour utiliser less et sass et éviter les erreurs à la compilation, il est préférable de transformer les.css en .less ou en .scss. Il y a des tools pour ça.

  • Martin

    J’ai également passé de LESS à SASS. Je le trouve plus performant. Maintenant, tout est question de goût. Pour ce qui est de CodeKit, le fait qu’il ne soit que MAC est un problème. Mais j’ai dernièrement testé l’application Koala qui permet de compiler à la volée du LESS, SASS, CoffeeScript et Compass et qui, de plus est gratuit et multiplateforme (MAC, PC, LINUX). Tu peux le télécharger à cette adresse si jamais tu veux l’essayer: http://koala-app.com/

    La seule chose qui aurait été bien avec cette application aurait été d’avoir liveReload d’intégré dedans. Mais bon, ce n’est pas la fin du monde :)

    • http://www.mathieurobin.com/ Mathieu

      Je suis en train de regarder du coup Sass et Compass, vu qu’ils sont intégrés à Yeoman et que j’essaie de basculer dessous

  • juju

    Le but de less n’est pas de minifier des css, c’est un préprocesseur css au même titre que sass/stylus.

    La minification est certes possible mais ce n’est pas le but premier de l’outil.

  • Mantis

    Salut,
    je n’ai pas tester LESS.
    Mais avec SASS + compass il est très simple de convertir jquery-ui en Sass et de le recompiler avec nos variables…

    Jettes donc un coup d’oeil à Sass qui me fait vraiment plaisir.

Articles liés