Soyons clair, je n’ai pas l’intention d’alimenter le débat sur l’opportunité ou non d’utiliser les préfixes vendeur. Si vous les utilisez, utilisez les bien, utilisez toutes les variantes de tous les vendeurs. C’est tout.

Non, mon sujet ici, ce sont tous ces scripts Javascript qui vont conditionner l’usage de CSS lorsqu’ils sont utilisés dans un navigateur Web. -prefix-free bien sûr, mais également less.js, respond.js, cssFX, mediatizr, WebFont loader, etc. Je n’ai pas ici la prétention de vous convaincre de ne pas les utiliser. D’une part parce que vous faites bien ce que vous voulez (c’est aussi ça le Web) et d’autre part parce qu’il m’arrive même à moi de m’en servir et ce serait quand même assez gonflé de ma part de vous dire « faites ce que je dit, pas ce que je fait »

L’idée, c’est plutôt de vous détailler les risques auxquels vous vous exposez pour que vous puissiez ensuite faire votre choix en votre âme et conscience.

Performance

L’usage de ces scripts induit un certain nombre de biais dans les performances de vos sites. Souvent, les scripts comme -prefix-free sont appréciés car « ils permettent de réduire le poids des CSS ». Ce qui est vrai mais au prix du poids du script lui-même (le jeu en vaut-il la chandelle) et de requêtes HTTP supplémentaires (vous êtes sûr de n’avoir aucun problème de latence ?).

Au delà de ces points largement discutables il y a tout de même quelques autres éléments à considérer :

1. Le rendu complet de votre site est suspendu au chargement de vos scripts. Le temps de rendu peut donc être altéré si vous êtes sur des connexions de mauvaise qualité comme du EDGE en réseau mobile. Cela peut se constater de manière bénigne avec la présence d’un léger FOUC ou bien plus gravement en cas de problème de chargement du script ce qui peut complètement casser votre design.
2. Le rendu devient également dépendant des performances globales d’exécution de vos scripts. Avec un seul petit script qui va agir sur une petite feuille de style, vous ne verrez jamais de problème. Mais que va-t-il se passer avec plusieurs centaines de Ko de scripts et de feuilles de style ? Par exemple, un script comme -prefix-free est un script linéaire : plus la feuille de style sera grosse, plus il prendra de temps pour s’exécuter car il l’examine entièrement. Que se passera-t-il alors si ce script est ralenti ou gêné ou traité après tous les autres scripts de la page (ce qui inclut vos scripts, mais également ceux que vous ne connaissez pas et qui sont utilisés par les extensions ou les bookmarklets de l’utilisateur) ?

Bref, utiliser ce genre de script vous fait consommer des ressources que vous pourriez utiliser pour des choses plus importantes que du style avec tout les effets de bords potentiels que je viens de vous énumérer.

Maintenabilité

Un des principaux avantages mis en avant pour ces scripts, c’est la simplification de la maintenance. Raphael Goetter l’a d’ailleurs bien expliqué sur son blogue. Là, je crois qu’il faut s’y arrêter quelques minutes.

Chaque script apporte son lot d’avantages, mais il apporte également son lot de problèmes. Aucun script n’étant parfait du premier coup, vous allez également devoir assurer sa maintenance. Il vous faudra le mettre à jour en fonction de ses propres évolutions ou prendre le risque de vous retrouver coincé avec un outil qui ne vous rendra plus les services que vous attendiez.

Il faut prendre en considération que ces scripts sont intimement liés à vos feuilles de style car plus vous les voudrez génériques plus ils seront volumineux et potentiellement bugués. Concrètement, cela veut dire qu’à chaque fois que vous allez mettre vos feuilles de style à jour, vous allez devoir vous assurer que le script fait bien son travail. Cela signifie plus de tests et en cas d’erreur, plus de temps pour débuguer car vous aurez alors deux sources d’erreurs potentielles.

C’est particulièrement vrai avec un script du type de -prefix-free. Pour vous épargner de saisir quelques lignes de CSS en plus, vous vous rajoutez un risque projet non-négligeable. Tant que ça marchera, oui, vous gagnerez du temps. Par contre, à la seconde ou vous allez rencontrer un problème, vous allez perdre beaucoup de temps. Sera-ce plus ou moins que le temps gagné ? Difficile à dire car cela dépendra énormément de votre connaissance des technologies en jeu ainsi que des outils que vous utilisez. Mais encore une fois, pourquoi prendre un risque là ou vous n’en aviez pas avant ?

Et l’utilisateur dans tout ça ?

Alors malgré tout ça, faut-il vraiment renoncer à utiliser tous ces scripts pourtant bien pratiques ? Il n’y a pas de réponse simple à ça. Pour être franc, il n’y a jamais de réponse simple en matière d’utilisation des technologies Web. Les contextes projets sont tous différents et certains justifient pleinement l’usage de ces scripts.

Néanmoins, avant de les utiliser, je vous invite à vous poser les questions suivantes :

1. Le script que je vais utiliser me permet-il de compenser un manque de compétences (techniques ou organisationnelles) de l’équipe projet ?
   Dans l’affirmative, cela reviens à essayer de mettre un pansement sur une plaie ouverte. Si la plaie est petite, cela permettra de patienter le temps que l’équipe se forme aux techniques requises. Si la plaie est profonde, ça ne fera que retarder le moment où il faudra prendre des mesures drastiques (et donc coûteuses) pour éviter l’infection.
   Préférez un bon plan de formation à moyen terme et à court terme, prévoyez l’intervention d’un développeur sénior capable d’épauler l’équipe. Si vous travaillez seul, faites l’effort de vous former ou changez de métier.
2. Le script que je vais utiliser est-il là uniquement pour mon propre confort ?
   Si c’est le cas, sachez que j’ai alors assez peu de considération pour vous (je sais, ça vous fait un belle jambe, mais au moins c’est dit). Ce genre d’attitude égoïste est exactement ce qui fait que le Web ouvert, standard et interopérable s’étiole. Si vous pouvez faire la même chose sans utiliser de script, faites le. Vous rendrez service à tout le monde en commençant par vous-même
3. Le script que je vais utiliser me permet-il d’améliorer l’expérience utilisateur ?
   Là, effectivement on peut sans doute se permettre de l’utiliser. L’utilisateur devrait toujours être votre point de référence. Quand vous réalisez un site Web, il y aura toujours au final un utilisateur qui va s’en servir. C’est compliqué de se dire qu’on travaille pour un utilisateur. En effet, trop souvent, les promoteurs et acteurs d’un projet se concentrent sur leur propres préoccupations. Les developpeurs et la pureté technique, les responsables métier et leur ROI, les chefs de projet et leur suivi budgétaire, Les designers et leur égo démesuré… autant d’écueils qu’on a tous un jour rencontrés. L’utilisateur, c’est un peu la petite lumière dans la nuit… ne le perdez jamais de vue, c’est votre bouée de sauvetage.

Alors voilà, malgré toute ma bonne volonté et même si je trouve que -prefix-free ou cssFX sont de très beaux projets, les utiliser revient, pour moi, à répondre « oui » à ma deuxième question. Vous comprendrez donc qu’en ce qui me concerne, je ne peux pas cautionner son usage sur un site en production. Je peux comprendre qu’on n’ait pas envie de passer des heures à maintenir des listes sans fin de propriétés préfixées. Mais dans ce cas, faites plutôt le choix des préprocesseurs CSS (LESS, SASS, etc.) qui vous permettront de manipuler des feuilles de style plus simples tout en vous assurant qu’elles comporteront bien tous les préfixes qui vont bien au moment de leur publication.

PS : Merci à Julien et Richard pour la relecture de mon orthographe déficiente