Je suis front-end développeur depuis 1998. A l’époque on appelait ça Webdesigner ou HTMLeur puis CSS Codeur etc… Cela consiste à assurer la production du code HTML, CSS et JS qui va être lu dans un navigateur. Comme beaucoup, j’ai commencé par faire n’importe quoi : des tableaux pour les mises en pages, des balises font pour modifier la typographie, et du JavaScript pour faire des validations de formulaires.
Puis j’ai vu la lumière : je me suis posé plein de questions sur le sens de ce que j’écrivais en terme de code et non plus en terme de rendu dans le navigateur.
Bref mettre du sens avant la forme. Je suis devenu ce que certains ont appelé un prophète des standards du Web, en préconisant une séparation stricte du fond et de la forme et en préconisant un respect du W3C, du WAI et en préconisant l’amélioration progressive : “the progressive enhancement ”.
Avec Nicolas et Denis, nous avons monté une agence web sur Rennes : artwaï en 2005. Dans une petite équipe avec des projets à taille raisonnable, il est facile de faire passer ces concepts. Mais aujourd’hui, artwaï c’est 10 salariés avec une collaboration étroite avec Polux et ces 9 intervenants et plus une dizaine d’indépendants. Comment fédérer autour d’une philosophie de développement, pour conserver l’identité propre d’artwaï ?
C’est ce message simple réactionnaire certes mais percutant et rock’n’roll que je passe régulièrement à tous :
Mais qu’est-ce que cela signifie concrètement ? Comment le vivre au quotidien ?
C’est ce que je vais tenter de vous expliquer.
JavaScript : état des lieux.
Selon les chiffres et ce que l’on constate tous les jours, JavaScript est une nuisance pour la performance. Si la tendance persiste, la page médiane expédiera au moins 400 Ko de code JS d’ici peu, et c’est simplement ce qui est transféré. JavaScript est presque toujours compressé. Si un serveur envoie 400 Ko de JavaScript compressé, la quantité réelle que les navigateurs doivent traiter après décompression est presque d’un mégaoctet. La capacité des appareils à faire face à ces lourdes charges de travail dépend, en fait, de l’appareil.
Quid de la réaction du smartphone moyen tournant datant de 2 ans ? Il s’étouffe. Même avec une connexion rapide, naviguer sur le Web est un exercice de patience car les pages Web chargées de JavaScript le bloquent pendant des périodes de temps considérables.
Or trop souvent les développeurs et intégrateurs pense leur “site web” comme une “application web”. La différence vient du cadre : ce qui n’est qu’un simple blog a-t-il besoin de la lourdeur d’un framework surdimensionné pour gérer des changements dans le DOM ou des requêtes asynchrones ? Je ne le crois pas.
De même, lorsque nous mettons en place le cadre d’une application web, les paquets installés introduisent des centaines, voire des milliers, de dépendances. Le tout construit à l’aide de compilateur dont la maîtrise devient un point critique où connaissance et vigilance deviennent indispensables. Cela nous oblige à vérifier la qualité du code produit sous les prismes du poids, de la rapidité et de l’accessibilité…
Pourtant l’environnement web est toujours le même. Les contraintes de réseaux et d’appareils ne disparaissent pas parce que l’on a poussé fièrement une application web ! Malgré tout… la dépendance du web vis à vis de JavaScript ne cesse de croître.
Je suis convaincu que la formation dans les technologies Web de base souffre de lacunes évidentes qui ont conduit à cet état des choses. Cette connaissance essentielle d’HTTP, HTML et CSS fait défaut. Or la réponse à cet engorgement réside dans ce savoir… Il est la clef pour apprendre à se passer de JavaScript.
Pour les animations :
No Fucking JS
HTML5 et CSS3 ont poussé vers la porte de sortie Flash Player notamment pour les animations. Toutefois, dans le web actuel il n’est pas rare de voir des animations d’objets réalisées en javascript ! Notamment avec la fameuse bibliothèque d’élément jQuery UI (82ko minifiée… no comment).
Mais pourquoi ? Le support de module animations de CSS est très bien répandu. Même Internet Explorer 10 permet de jouer des animations en CSS.
Animation et transition dans la visualisation d’un élément d’une page web font partie de la forme du contenu. Or si le fond, le sens, est réservé à HTML, la forme est l’apanage du CSS. Et non pas du fucking javascript ! Dès lors on ne saurait que vous recommandé d’utiliser les @keyframes, pour définir des animations qui peuvent jouer sur une multitude de paramètres :
- le déplacement,
- l’échelle,
- l’inclinaison,
- l’opacité,
- la couleur,
- la rotation,
- et d’autres…
Puis de les appliquer selon des critères tout aussi variés :
- le délais de démarrage,
- la vitesse,
- la phase d’accélération et de décélération,
- le nombre d’itération,
- le sens de lecture,
- etc
Pour les interfaces :
No Fucking JS
Pour illustrer mon propos, une simple anecdote. Dans le cadre d’une mission pour une SSII il y a quelques années sur une interface de gestion, on m’a demandé de faire en sorte que le formulaire soit envoyé quand l’utilisateur appuyait sur la touche Entrée… et ce alors que le formulaire n’avait pas et ne devait pas avoir de bouton d’envois.
Ma première réaction fut d’insister pour qu’on mette un bouton pour l’accessibilité. Refus catégorique. Or, lorsque ce bouton est présent le comportement voulu est induit. Pas besoin d’une seule ligne de JavaScript. C’est pourtant que ce qu’avait commencé le développeur du bureau d’à côté. Un beau code javascript qui capturait un event selon une code de frappe au clavier (NB : on trouve encore des bouts de code pour faire ce genre de chose qui me semble être une aberration).
Pour résoudre le problème, il m’a suffit d’ajouter ce bouton d’envoi dans l’HTML et de le rendre invisible en CSS.
En effet, un développeur Front-End doit – à l’instar d’une blondinette animée des années 80 – faire preuve d’un peu d’astuce et d’espièglerie. Ainsi il ouvre le champ des possibles des interfaces sans JavaScript :
- menu déroulant,
- onglets,
- accordéon,
- popin,
- carrousel,
- visionneuse d’images,
- et bien d’autres…
Pour les formulaires :
No Fucking JS
Depuis HTML5, les formulaires <form> ont largement progressé et l’implémentation des nouveaux attributs est largement répandu. Par exemple, nous pouvons désormais “typer” les inputs et laisser le navigateur en faciliter la saisie et en faire le contrôle avant l’envois du formulaire. On peut citer les types suivantes :
- tel (pour un numéro de téléphone),
- url,
- email,
- number.
Au-delà des types fournis par la norme HTML 5, nous pouvons désormais définir nos propres règles de validation avec l’attribut pattern déterminé selon une expression régulière. Des éléments de formulaire en HTML peuvent aussi devenir plus ergonomiques avec des éléments de saisies plus simples pour l’utilisateur et pour les intégrateurs web.
- l’autocomplétion de premier niveau avec datalist,
- range,
- date, time, month, week et datetime-local
JavaScript ne devrait intervenir que dans un second temps après avoir épuisé toutes les solutions natives à base d’HTML et de CSS.
De CSS ? Oui de CSS ! Les feuilles de style permettent aujourd’hui d’utiliser une interface pour la saisie des formulaires plus simple, sans dénaturer le code HTML. Par exemple, plutôt que d’utiliser un framework JS pour transformer un select en une liste de case à cocher ; pourquoi ne pas utiliser directement des inputs type checkbox ?
Et ceci n’est qu’un exemple parmi tant d’autres…
Pour la web performance :
No Fucking JS
Comme dit précédemment, le poids et l’exécution du Javascript pénalisent la web performance. Mais au-delà de cela, avec des solutions type angular, react ou vue.js leur principe est de charger le cœur de l’interface au premier chargement puis de ne requêter que de la donnée JSON quand cela est nécessaire. Pourquoi pas mais… Cela signifie que le premier chargement est plus long…
Or c’est la première impression qui compte et comme :
53% des personnes quitteront une page mobile si elle prend plus de 3 secondes à se charger.
A vous de choisir…
Pour le référencement :
No Fucking JS
Au-delà de la vitesse d’affichage nécessaire à un bon référencement, le parcours par les moteurs de recherche des pages web dépendantes de JavaScript est plus que précaires. Au moindre pépin dans le traitement, l’indexation est imparfaite… pire… Elle échoue !
Avec angular, react ou vue.js, certains utilisent des solutions de pre-rendering à la limite du cloacking ! (Le cloaking est une technique utilisée par les hackers mal intentionnés pour optimiser leur positionnement dans les moteurs de recherche.) Cette technique consiste à présenter un contenu de page web différent suivant que le client distant est un robot de moteur de recherche ou un internaute humain.
Du coup, cela rajoute encore une couche de complexité supplémentaire (qui nécessite un contrôle régulier) qui va, au minimum, doubler voir tripler les temps de recette SEO. Et je ne parle pas de l’inertie de l’indexation des robots qui peut prendre plusieurs mois…
Quelle est la bonne solution ?
Non, malgré la tendance actuelle, je ne serai pas la mouche du Cochet et donc je ne serai pas un collapsologue du web. Et No Fucking JS Spirit ne veut pas dire No JS tout court ! C’est tout l’intérêt du Spirit en bout de ce leitmotiv. Car il faut savoir séparer le bon grain de l’ivraie !
En effet, si vous êtes arrivé jusqu’à cette phrase dans cet article, c’est qu’il vous semble bien qu’il y a un souci dans la course au tout JavaScript. Cette course effrénée qui, à terme, engendra une dette technique abyssale si nous ne nous responsabilisons pas. Bref passons au Javascript Responsable et non plus au Fucking JS. Nous devons cette formule de JavaScript responsable – certes à une tendance de fond dans notre société actuelle où tout doit devenir “responsable” – mais surtout à l’éducation plus policée que la mienne de Jeremy Wagner.
Que le message soit JavaScript Responsable ou No Fucking JS, la finalité est la même : aboutir à une qualité de page web, plus pérenne, plus inclusive et plus webperfée il va s’en dire.
Dès lors, nous avons décidé de porter la bonne parole de Jeremy Wagner en vous recommandant chaudement de lire ses articles,
- soit leurs traductions dans la langue de Molière que nous vous proposons dès aujourd’hui :
- en commençant par JavaScript Responsable : 1ère partie.
- soit dans leur langue d’origine :
- paru en mars 2019, Responsible JavaScript : Part I,
- disponible depuis juin 2019, Responsible JavaScript : Part II,
- publié en novembre 2019, Responsible JavaScript : Part III.
Bonne lecture à tous.
