La dégradation élégante peut sauver votre site

C'est une des règles de bonnes pratiques qui arrivent enfin à la mode. À mon avis, c'est une méthode ingénierie qui va dans le bon sens : tester la présence d'un outil avant de s'en servir, et palier à son absence.

EDIT : Comme me l'a fait remarquer Wiko dans son commentaire sur Google Plus : « Quand tu dis “dégradation élégante”, le client comprend ça va être moins bien alors que quand tu dis “amélioration progressive”, le client comprend cela va être de mieux en mieux (même si c'est quasi la même chose) ». En soit, il n'a absolument pas tord. J'utilise juste le terme “historique”.

TL;DR : sautez à ce chapitre.

Rappelons ce qu'est Javascript

C'est un langage interprété qui est utilisé un peu partout : Sur quasiment l'ensemble des navigateurs web, tous les MSIE, Gecko, Webkit, mais aussi les téléphones, téléviseurs, tablettes brailles et systèmes vocaux. En fait, il a quitté les navigateurs depuis un bail : On s'en sert pour construire des requêtes de données (CouchDB, que, ceci dit, je ne vous recommande pas des masses), en tant que serveur web (NodeJS en tant que serveur et langage d'interprétation persistant et mono-thread) et même dans le tout dernier SimCity.

En fait, Javascript est devenu un langage tout-terrain susceptible d'être interprété de n'importe où. AFAIK Sur de l'embarqué à haute-contrainte, on préfère envoyer directement le binaire JVM putôt que le source Java. Doit bien avoir le kernel Linux qui doit avoir une plus grande versatilité, mais lui aussi est précompilé, et parfois sur des architectures tierces pour des cas vraiment exotiques.
Bon, évidemment, comme il est interprété sur la plateforme, cela a ses inconvénients. Notamment vérifier le support de la version du langage (ECMA6, anyone ? ah ben non, c'est ce vieillissant V8), des constructions et des API. C'est le cœur du sujet.

Pour cet exemple, on ne va pas parler d'internet

C'était Samedi dernier, alors que j'étais en plein direct. Être en « plein direct » pour mon émission de radio, cela signifie animer, lire (un peu trop) mon texte, passer la musique en flux continu et mixer le son. Beaucoup de choses à la fois.

Et pour mixer le son, on utilise une table de mixage.

Une table de mixage, c'est une suite de potentiomètres qui font entrer plus ou moins de courant de différentes prises, et à la sortie, elle mélange tous ces courants. Oui, je sais, je suis mauvais en explications techniques. Mais n'est pas Fred et Jamy qui veut…

Enfin, ça, c'était avant. Et dans une radio associative dite “rock”, ça signifiant que la table de mixage baignait dans de la bière, des cendres, des miettes, bref, ça pouvait être un vrai nid à faux-contacts. Tu montais le son d'une platine disque, son crachaît, sur un micro, ça vombrait, et des fois, une seule sortie fonctionnait. Ça donnait une certaine “chaleur” au son, qui était tout sauf agréable.

Jusqu'à il y a 12 ans, quand on a enfin décidé de passer à une table de mixage semi-numérique. On avait choisi à l'époque la Airlab de D&R, et on y est restés fidèles. Celle-ci comporte une surface de contrôle tout à fait traditionnelle : potards verticaux, rotatifs, boutons poussoirs, prises de casques avec les mêmes fonctionnement qu'à l'ancienne, celle qui fait qu'un DJ sait s'en dépatouiller, et qu'un ingénieur du son sait que le truc marqué “bass” n'est pas un générateur de couilles.
Et un ordinateur d'assistance.
Celui-ci permet de créer des groupes de pistes, de gérer le rouge antenne, de contrôler par auto-start les lecteurs, de couper automatiquement les micros si une piste son est montée, etc…

Sauf que Samedi dernier,

la table était plantée.

Et là, on apprécie que le fonctionnement du système ne soit pas complètement lié à l'ordinateur.

Pendant que l'afficheur et une partie des fonctions plantaient allègrement, j'ai réalisé l'émission sans un seul pet sonore à l'antenne. Baissant, montant mes potards, avec le comportement voulu à l'antenne. En plein direct, j'ai pu déplanter la régie finale de la radio sans que personne ne s'en soit rendu compte ^①.

La dégradation élégante, c'est ça

C'est comme une direction assistée. C'est super pratique, mais si ça plante, la voiture doit rester gouvernable.

Or, il y a milles raisons pour que vos javascripts ne marchent pas : navigateur trop vieux, coupure de réseau en plein milieu, faute de frappe, erreur de compréhension d'une fonction, polyfill mal conçu ou de trop ^②,… Et dans ce cas, il est important que votre site puisse rester un minimum fonctionnel.
Alors certes, il sera tristounet sans ce <canvas />, sans les interactions <svg></>, sans mode AJAX,… Mais tout ne sera pas complètement ruiné.

Découpez un max vos fonctions. Si l'une d'elle part en vrille, elle ne doit pas faire s'effondrer le reste trop vite. Toute la responsabilité de votre code ne doit pas être liée à trop de sections communes. Ou alors, la plus légère possible.

Faites plantez votre code. Dans votre batterie de test, n'hésitez pas à tentez des typos, à surcharger des API récentes pour voir ce qu'il peut se passer sans. Cela s'appelle du fuzzing. Je vais vous surprendre, mais Microsoft teste depuis 20 ans ses programmes (suite office, navigateur) en leur faisant ouvrir des documents aberrants et voir ce qu'il se passe.

Testez vos formulaires de validations avec IE8. La vérification prophylactique des navigateurs, c'est super, mais n'oubliez surtout pas de vérifier que vos fonctions serveurs font aussi leur boulot. C'est une question de sécurité ^③. D'ailleurs, justement, ce matin, heureusement que l'on teste sous MSIE8.

Et surtout, essayez de coller aux standards. C'est idiot, mais oui, ils sont utiles. Pensez à utiliser les balises HTML pour ce qu'elles sont. Évitez d'appeler des API javascript préfixées, comme vous tenterez d'éviter les préfixes CSS. Et si un hack vous semble disgracieux, ne laissez pas de place au doute, car il fera sûrement planter votre code dans les futures versions des navigateurs.

Moi aussi, j'ai eu ma période wizzzz où j'ai fait des tartines de codes gigantesques, où j'ai montré comment s'éclater dans le layout, modifiant milles et un nœuds à la fois. Et un jour, je me suis dit « mais si javascript ne marche pas, et que je mette du temps à déplanter… ». Des fois, y songer vous permet d'anticiper de gros bugs, voir que le public ne se rende pas compte d'un souci important. Lightbox est élégant, car si vous cliquer direct sur l'image avec le bouton du milieu, vous aurez quand même une image. Alors que les loaders JS de Flash, berk berk berk

Et là, ça change tout

Restez propres, pensez toujours à tester les fonctions disponibles sur les navigateurs. Pensez à un plan B. Et ne vous inquiétez plus pour les utilisateurs de MSIE7 ou Netscape 4 : Ces gens sont habitués à avoir des sites qui ne marchent pas. Google, Yahoo, et pratiquement tout le monde les ignore.

Sauf qu'il ne faut plus penser en terme de navigateurs cibles immédiats, mais aux navigateurs futurs. Or, aux dernières nouvelles, certains OS peuvent retirer certaines fonctions, certains API, voire des propriétés CSS à leur convenance. Donc, il faut réfléchir en terme de ce qui est disponible, et pas en termes de marques.

Restons dans le son, exemple sans Javascript

Voici le code permettant d'“afficher” le sonore de l'émission sur mon blog et sur le site de l'émission. Dégradation élégante sans une seule once de javascript.

<audio controls="controls" style="vertical-align:middle;width:720px;" src="http://dascritch.net/vrac/Emissions/SuppWeekEnd//343-SupplementWeekEnd%2816-03-13%29.ogg" type="audio/ogg; codecs=vorbis"> <source src="http://dascritch.net/vrac/Emissions/SuppWeekEnd//343-SupplementWeekEnd%2816-03-13%29.ogg" type="audio/ogg; codecs=vorbis" /> <source src="http://dascritch.net/vrac/Emissions/SuppWeekEnd/podcast/343-SupplementWeekEnd%2816-03-13%29.mp3" type="audio/mpeg" />  <object style="vertical-align: middle; width: 720px; height: 20px;" type="application/x-shockwave-flash" data="/interface/player_mp3.swf">  <param name="src" value="/interface/player_mp3.swf" /> <param name="FlashVars" value="mp3=http://dascritch.net/vrac/Emissions/SuppWeekEnd/podcast/343-SupplementWeekEnd%2816-03-13%29.mp3&loadingcolor=304b5f&bgcolor1=ffffff&bgcolor2=e6f4ff&buttoncolor=304b5f&buttonovercolor=000077&slidercolor1=6096BF&slidercolor2=304b5f&sliderovercolor=000077" /> <param name="wmode" value="transparent" /> Cette fonction nécessite<ul> <li>une sortie son.</li> <li>un plugin lecteur de média ogg vorbis ou mp3. VLC est un bon choix.</li> <li>ou le plugin Adobe Flash ou compatible.</li> </ul> </object> </audio>

Eh oui, la dégradation élégante, ça date pas d'hier :

<audio></> fait comme <object></> : les navigateurs qui ne le comprennent pas en affichent le contenu. Dégradation élégante, hack classieux
<source /> fait comme <param /> : il permet au navigateur qui comprend la balise parente mais qui n'a pu la lancer de trouver une solution de repli
Par contre, les commentaires conditionnels de MSIE sont des hacks dégueulasses, bannis depuis MSIE9 à raison

Et maintenant ?

À vous de faire attention. Cela vous économisera du temps pour débugguer sur les navigateurs défaillants et vous en fera gagner avant qu'un bug en prod ne se fasse repérer.

PS

① sans que personne ne s'en soit rendu compte: Ce qui explique bien souvent que je n'écoute pas toujours d'une oreille très attentive les chroniques de mes collègues. Je suis désolé pour eux.
② un polyfill mal conçu ou de trop: Un polyfill est une bibliothèque javascript qui tente justement d'expliquer à un vieux navigateur les rudiments du web moderne. C'est donc une solution de dégradation élégante. Hélas, le vieux navigateur, il risque de planter si on lui en met trop.
③: Merci à Mathieu “Pictode” et Guillaume Lacasa pour la récupération de la fin de ce billet et à Tau pour l'asile technique. Ouf !