Chez Jérémie - Mot-clé - javascript

Lier CSS à Javascript : une mauvaise idée

Jeremie — Mon, 13 Feb 2012 09:30:00 +0100

J’ai récemment lancé un twitt qui a généré un nombre important et plutôt surprenant de réactions. Vous n’êtes pas sans savoir qu’actuellement, l’utilisation des préfixes vendeur en CSS est une source de grande tension. Parmi toutes les solutions qui existent pour essayer de limiter l’impact de l’usage de ces préfixes, le script -prefix-free de Lea Verou est une solution actuellement très en vogue… mais dont je déconseille très fortement l’usage.

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 :

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

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

Rendre une application AJAX bookmarquable

Jeremie — Thu, 22 Oct 2009 11:39:00 +0200

Parmi les reproches communément adressés aux applications AJAX on retrouve un grief assez récurrent : l'impossibilité d'utiliser les favoris. Dans cet article, je vais vous expliquer comment gérer les favoris (en anglais "bookmarks" d'où l'horrible néologisme du titre) avec une application utilisant AJAX. C'est beaucoup plus simple qu'il n'y paraît.

Beaucoup d'architecture

Avant même de penser à coder, il va falloir commencer par se poser un certain nombre de questions de nature architecturales. En effet, l'utilisation d'AJAX "pervertit" l'usage normal que l'on peut avoir d'un navigateur. Traditionnellement, un navigateur charge des documents (on parle aussi de ressources) identifiés par leur URL via le protocole HTTP le plus souvent. Le navigateur permet de passer d'un document à l'autre (via des liens hypertexte) ou éventuellement de modifier le document (via des formulaires) et d'en charger l'intégralité de la version modifiée. AJAX distord ce fonctionnement. Avec cette technique, le navigateur charge un seul document et va en modifier certaines parties en fonction des actions de l'utilisateur.

Entre ces deux approches, les mécanismes techniques mis en œuvre sont fondamentalement les mêmes, mais c'est leur mise à disposition à destination de l'utilisateur qui diffère. D'un côté, l'utilisateur accède à N documents et de l'autre, il accède à un seul document qui se modifie en permanence. C'est sur ce dernier point que réside la difficulté liée aux favoris : ce que l'on met en favoris, c'est l'URL d'une ressource !

La notion de contexte

HTTP se caractérise par une absence de contexte. C'est cette spécificité qui permet de mettre en favori n'importe quelle URL. En effet, sur cette base, une URL pointera en théorie toujours sur le document que l'on a vu. Le problème si vous mettez en favori une application AJAX, c'est que vous ne mettrez en favori que l'état initial du document, et pas l'état dans lequel se trouve votre document au moment où vous enregistrez votre favori.

Donc, comme on le voit, AJAX créée un document avec un contexte : l'état dans lequel il est à un instant T. Et ça, les navigateurs web ne savent pas le gérer nativement.

Une application AJAX a donc deux problèmes à résoudre :

L'application doit disposer d'un mécanisme permettant de définir le contexte courant du document et l'exploiter le cas échéant.
Les navigateurs ne savent mettre en favoris que des URLs

Cela signifie donc que pour rendre un application AJAX bookmarquable, le contexte du document doit être stocké dans l'URL. Or, comment modifier une URL sans recharger le document (ce qui ferait perdre tout le bénéfice d'AJAX) ?

La structure d'une URL

La structure des URLs va nous aider à voir où l'on peut stocker des paramètres de contexte. De manière simplifiée, une URL est structurée comme suit :

Le protocole : En général HTTP dès que l'on est dans un cadre Web.
Le domaine : Il est de la forme sous-domaine.domaine.extension. Il permet d'identifier la machine à qui on va demander le document qui nous intéresse.
L'emplacement du document : Il est de la forme /dossier/sous-dossier/fichier
Les paramètre de requête : Ils sont de la forme ?paramètre1=valeur1&paramètreN=valeurN. Ces paramètres peuvent influer sur la nature profonde d'un document ou sur son contenu.
Une éventuelle ancre nommée : Elle est de la forme #mon-ancre. Elle a pour vocation de cibler un élément identifié dans le document et, le cas échéant de positionner cette partie du document dans la zone visible de la fenêtre du navigateur.

Assez instinctivement, on serait tenté de positionner nos informations de contexte en tant que paramètre de requête. Effectivement, si on met en favori une URL avec des paramètres permettant de connaitre le contexte, on aura bien l'effet attendu. Malheureusement, si vous modifiez les paramètres de requête de l'URL, un navigateur va envoyer une requête HTTP et recharger la page, ce qui va à l'encontre de ce que l'on veut puisqu'on est en AJAX.

La gestion des URL par les navigateurs

De manière générale, toute modification de l'URL du navigateur conduit le navigateur à lancer une requête HTTP afin d'obtenir la dernière version du document correspondant. C'est aussi vrai pour les paramètres de requête. Après tout, si on modifie les paramètres, il faut bien que celle-ci soit relancée afin que le serveur puisse fournir le document correspondant.

Il y a néanmoins une exception à cette règle : la modification de l'ancre nommée.En effet, pour le navigateur, l'ancre nommée représente un élément présent dans le document courant et qu'il faut atteindre. En conséquence, on ne change pas de ressource (contrairement à une modification des paramètres de requête), mais on cherche à atteindre un point de la ressource courante il n'est donc pas nécessaire de lancer une nouvelle requête HTTP, au contraire, ce serait contre productif.

Alléluia, c'est donc là que se situe le salut du développeur d'application AJAX : utiliser l'ancre nommée pour stocker le contexte de son application dans l'URL.

Oui mais...

Il y a contexte et contexte. On pourrait philosopher pendant des heures et des heures sur ce détournement des ancres nommées dans un contexte AJAX. D'un point de vue extrêmement prosaïque, c'est la seule solution qui marche si on veut pouvoir utiliser les favoris du navigateur. Par contre, ce n'est pas parce que ça marche qu'il faut faire tout et n'importe quoi. Placer l'intégralité d'un contexte applicatif à cet endroit n'est pas pertinent et potentiellement dangereux pour votre application : un utilisateur peut modifier cet élément de lui-même, on ne peut donc pas lui faire confiance. Ainsi, si vous placez un ensemble de variables en clair à cet endroit, vous vous exposez à des risques d'attaque de votre application. Il existe des tas de façons de stocker les données du contexte applicatif, que ce soit localement (les mécanismes "Session Storage" ou "Local Storage" de HTML 5 ou leur succédané des divers frameworks Javascript) ou sur un serveur distant (beaucoup plus sûr architecturalement parlant, mais plus problématique pour gérer la notion de "offline"). N'utilisez les ancres nommées que pour stocker un identifiant du contexte applicatif. Vous en retirerez des avantages pour vous et pour vos utilisateurs :

Pour vous : vous pouvez renforcer facilement la sécurité de vos applications tout en pouvant enrichir votre contexte applicatif sans changer vos mécanismes de gestion des URL.
Pour votre utilisateur : son URL reste lisible (voire compréhensible si vous gérez bien vos identifiants de contexte) et relativement légère sans exposer ses données.

Un peu de code

Maintenant que nous avons vu les bases théoriques, comment mettre ça concrètement en œuvre ?

window.location est mon ami

Vous faites de l'AJAX, donc vous faites du Javascript, et si vous faites du Javascript, vous avez accès à l'objet window.location. Cet objet vous donne accès à l'URL courante du navigateur et vous permet de la modifier.

Lire l'URL courante : var URL = window.location.href

Lire l'ancre nommée (elle commencera par le caractère #) : var ANCRE = window.location.hash

Modifier l'ancre nommé :

/* Récupération du contexte actuel */
var AncreOLD = window.location.hash;

/* Récupération de l'URL courante */
var URL = window.location.href;

/* On supprime l'ancienne ancre de l'URL */
URL = URL.substring(0, URL.length - AncreOLD.length);

/* On créée une nouvelle ancre */
var AncreNEW = Math.round(Math.random()*1000);

/* On met à jour l'URL dans la barre d'adresse du navigateur */
window.location.replace(URL + '#' + AncreNEW);

Le petit script ci-avant vous montre les étapes clés de la modification de l'URL du navigateur. A vous de l'adapter à votre propre contexte applicatif, mais basiquement, tout est là.

Et voila !

Oui, oui, ce n'est pas plus compliqué que ça. Avec ce que vous avez vu là, vous êtes capable de rendre vos applications AJAX bookmarquable. Ceci dit, maintenant, il vous reste à faire le plus compliqué : gérer votre contexte au niveau applicatif. Sur ce point, chaque application a ses spécificités et ses besoins. N'hésitez pas à aller voir ce qu'ont fait d'autres développeurs à ce sujet. La première chose à regarder c'est ce qu'offrent les framework Javascript pour gérer cela nativement. Ensuite, si vous en avez le courage, vous pouvez aller voir ce que font des gens comme Google (Gmail, Reader et Wave sont extrêmement instructifs à cet égard... mais c'est horriblement touffu !).

Un gros merci au deux bisounours d'amour que sont Virginie et Stéphane pour le sauvetage orthographique de ce billet