Les programmes coté navigateur

Ils sont quelquefois nécessaires

A l'origine du web, le langage HTML a été conçu pour diffuser du texte et des images. Déjà au siècle dernier, les navigateurs disponibles étaient capables de le faire.

On pouvait aussi dès le début télécharger des fichiers de toute nature.

Mais certains ont réalisé des sites web demandant au navigateur de faire des choses qui n'avaient pas été prévues au départ, comme de montrer des vidéos.
Dans ce cas, c'est un programme distinct du navigateur web, lancé par lui, qui se charge de faire le travail.

Les vidéos constituent un cas particulier. Une nouvelle version du langages HTML a permit de les intégrer dans les pages d'un site. Les navigateurs d'aujourd'hui sont capables de montrer des vidéos de manière autonome. Dans le cas du format mp4 qui était soumis à des brevets, Mozilla Firefox permet de le faire sous GNU/Linux depuis 2014, mais ça a du l'être plus tôt avec d'autres systèmes d'exploitation propriétaires et payants.

Actuellement, lorsque du son ou une vidéo est enregistré dans un fichier, tous les navigateurs peuvent en diffuser le contenu. Par contre, la transmission de son et d'images en direct, qu'il s'agisse de télévision ou de vidéoconférences, n'est pas supportée nativement par le langage html et donc par les navigateurs web. Ils font donc appel à des programmes tiers.

Mais cela n'explique pas que certains sites web exigent des versions de navigateur de plus en plus récentes pour continuer à fonctionner. Par exemple, Youtube a fonctionné dans le passé avec la version 12 (2012) de Firefox et peut être auparant avec les versions 3 (2010). Mais alors que depuis sa version 27, Firefox est capable nativement de montrer des vidéos, youtube refuse maintenant de fonctionner avec cette version ou la version 31. Un numéro de version d'au moins la 5ème dizaine est devenu nécessaire. De même, pour les diffusions vidéo en direct, elle fonctionnaient très bien il y a quelques années avec Firefox 52, mais il faut à présent une version d'au moins la 6ème dizaine (62) pour continuer à voir ces vidéos.

De nombreux sites web participent à la surenchère des numéros de version des navigateurs en devenant incompatibles avec d'anciennes versions de navigateur sur lequel ils fonctionnaient auparavant.

Ce n'est pas le cas pour tous les sites web. Ainsi, le jeu massivement multi-joueurs Travian qui existe depuis 2005 utilise Javascript pour afficher divers compteurs (variation dans le temps de la quantité des différentes ressources d'un village, temps restant pour finir une construction, pour l'arrivée de marchands ou un déplacement de troupes), ce qui fait que les données numériques de la page sont actualisées en permanence alors qu'une nouvelle version de la page n'est envoyée par le serveur web que lorsqu'un événement est survenu.

C'est un cas où l'utilisation de petits programmes (en javascript) coté navigateur est nécessaire. Et le système qu'ils ont développé il y a plus de 10 ans fonctionne toujours, aussi bien avec des navigateurs devenus anciens, qu'avec des versions récentes. A part la sécurisation des données de plus en plus ellaborée par le protocole https qui fait qu'en 2021, de plus en plus de sites ont arrêté de fonctionner avec Firefox 31, l'exemple de Travian montre qu'on pouvait déjà créer des automatismes avec javascript il y a plus de 10 ans et permet de douter de l'utilité d'évolutions qui ne fonctionnent qu'avec des navigateurs récents.

En abuser peut nuire à l'ergonomie

Certains moteurs de recherche et certains wikis (notamment) font des propositions à partir des premières lettres tapées d'une demande.
Dans la mesure où ce sont juste des suggestions, qu'on peut cliquer sur l'une d'elles pour gagner du temps, ou au contraire les ignorer, ce système qui suppose que le serveur récupère en temps réel chaque caractère saisi au clavier ne pose pas de problème.
Mais tous les sites web n'utilisent pas ce genre de mécanisme à bon escient.

Cas du serveur FOG

FOG (Free Open Ghost) est un logiciel libre qui permet d'enregistrer des images de disques durs d'ordinateurs et de les cloner sur d'autres ordinateurs avec lesquels le serveur FOG communique en réseau.

Le pilotage du serveur FOG se fait avec un navigateur web.

L'interface utilisateur du serveur FOG permet de gérer :
La sélection des hôtes est probablement l'action sur le serveur qu'on effectue la plus fréquemment. Pour celà, il y a une zone de saisie sans bouton de validation associé :



On va donc taper quelque-chose dans la zone de saisie. Déjà, on ne la trouve pas vierge et la saisie de caractères n'efface pas forcément l'indication précédemment affichée (comme si l'indication "Chercher" au dessus ne suffisait pas !). Un effacement manuel de ce contenu inutile va faire perdre du temps.

On tape alors le premier caractère du critère de recherche et le serveur FOG affiche immédiatement la liste de tous les ordinateurs (hôtes) qu'il connait avant de la corriger pour ne garder que certains.

On tape un deuxième caractère et le même processus se produit.

Quand on a fini la saisie, on s'aperçoit que certains ordinateurs sélectionnés n'ont pas leur nom qui correspond à ce qu'on a tapé ! Peut être que la chaine "af" recherchée figure ailleurs dans le description de ces ordinateurs, mais dans ce cas, le minimum serait de demander à l'utilisateur à partir de quoi on doit faire la recherche !

Donc déjà 3 défauts :
Ensuite, une fois qu'on a la liste cherchée à l'écran, il peut être utile de l'enregistrer dans un fichier. Sauf que si on le fait, au lieu de récupérer une page HTML avec à l'intérieur l'information utile, on récupère une page HTML avec le gros programme javascript qui a permit au navigateur d'afficher cette information !

Au lieu d'utiliser du javascript pour faire n'importe quoi, un formulaire de saisie du critère de sélection avec un bouton de validation à cliquer une fois la saisie terminée permettrait grâce à un programme PHP d'avoir le résultat plus rapidement sans affichage intermédiaire parasite, et ce résultat figurerait dans le code source de la page HTML produite.

Il y a un cas où l'utilisation de javascript est nécessaire dans l'interface web du serveur FOG. C'est pour la page qui affiche les taches en cours d'exécution (capture d'image ou clonage) avec un suivi de leur progression.
Mais pour toutes les autres pages de l'interface web de ce serveur, le traitement des demandes entièrement en PHP donnerait de bien meilleurs résultats à la fois en vitesse de traitement et en agrément d'utilisation.

Cas d'un site de vente d'ampoules LED

Un site marchand propose à la vente des ampoules LED et des luminaires. Pour les ampoules LED vissantes avec un culot E27, plus d'une centaine de modèles sont proposés. Aussi, un menu permet de sélectionner les ampoules qui obeissent à certains critères.

Un premier critère proposé est le prix. Pour cela, on a un formulaire de saisie avec le prix minimum, le prix maximum et un bouton de validation.



Pour ce critère, pas de problème. Grâce au bouton de validation, la page affichée n'est actualisée que lorsqu'on a fini d'indiquer la gamme de prix acceptée.

Un deuxième critère proposé est la puissance de l'ampoule. Pour cela, on dispose d'une longue liste de cases à cocher (la dernière puissance proposée est 100 W), qui n'est pas munie d'un bouton de validation !



Résultat, à chaque fois qu'on coche ou qu'on décoche une case, la page du site met plusieurs secondes à se réafficher pendant lesquelles on ne peut pas accéder à la liste des cases à cocher pour continuer d'indiquer dans quelles gammes de puissance on fait la recherche.
Coté utilisateur, ça fait une perte de temps, et coté serveur web, ça fait du temps de traitement en plus pour la préparation de pages intermédiaires qui ne serviront pas.

Dans ce cas de ce site, il est possible que le traitement de la liste des puissances choisies soit fait entièrement en PHP, mais le problème d'ergonomie vient du fait que chaque action sur une case à cocher entraîne le réaffichage de la page au lieu d'attendre que l'utilisateur clique sur un bouton pour traiter d'un coup toute la sélection qu'il a effectuée.

Cas d'un serveur du CNED

Le cas du serveur permettant d'autoriser des élèves à suivre un enseignement à distance est similaire à celui de la sélection de puissance des ampoules LED.

En france, la pandémie COVID 19 a emmené le ministère de l'éducation nationale à demander aux professeurs à faire de l'enseignement à distance. Pour celà, la plateforme de vidéoconférences du Centre National d'Enseignement à Distance a été utilisée.

Elle dispose d'une salle d'attente pour autoriser les élèves entrants à suivre la conférence. Elle est visiblement réalisée en javascript avec 2 listes :
Le professeur doit cliquer un par un sur les élèves en attente pour les accepter. A raison de 5 secondes par élève (dans un cas favorable !) pour que le serveur prenne en compte une acceptation, il faut plusieurs minutes pour accepter une classe complète.

L'utilisation de formulaires PHP avec des cases à cocher, un bouton de validation pour les sélections partielles, et un autre pour sélectionner en bloc tous les entrants, aurait fait gagner un temps précieux tout en limitant la charge du serveur qui aurait eu des requêtes à traiter moins fréquemment.

Certes, les serveurs du CNED ont été conçus pour les enseignements à distance que le CNED dispense, c'est à dire beaucoup moins d'enseignements que pour la moitié ou l'ensemble des classes d'un pays. Mais après le confinement de 2020, travailler sur le fonctionnement de ce serveur pour que la validation des élèves entrant ne prenne pas un temps monstrueux aurait été utile. Et si en plus, il y avait eu la possibilité d'avoir la liste des élèves acceptés par ordre alphabétique, plutôt que par ordre d'arrivée (pour ça, il existe une fonction de tri en PHP), il aurait été plus simple de noter les présents, et donc de trouver es absents.
Il suffisait de se pencher sur le problème.