Le blog de Philippe Poisse

Côté utilisateur

Bon un script répété 70 fois c’est relativement rare. Si le concepteur d’un site a de vraies compétences en développement il ne fera pas une erreur pareil. À mon avis, dans  ce genre de cas on est face à un infographiste qui utilise un RAD (genre Dreamweaver) en mode WYSIWYG ou un CMS en y mettant du code JavaScript sans trop savoir ce qu’il fait.

La plupart des gens commence comme ça, moi y compris. Mais quand on vend des prestations, on s’assure de les maîtriser.

Le gros soucis c’est l’usage quasi-systématique du JavaScript depuis qu’AJAX est arrivé.

« Le rapport ? » me direz-vous. Et bien avant AJAX les développeurs Web évitaient le JavaScript. (ça peut se comprendre) ; après AJAX tout le monde veut utiliser un framework.

Le meilleur exemple, à mon sens, ce sont les trackeurs. J’utilise Ghostery pour avoir la liste des trackeurs des sites que je visite et les bloquer. C’est fréquent de tomber sur une petite vingtaine de ces bestioles.

Un autre exemple est la réalisation d’effets visuels à l’aide de JavaScript, les menus déroulants notamment.
Pour l’internaute le résultat est simple : ralentissement de la navigation.

Malgré AJAX la majorité des scripts est synchrone, c’est à dire qu’ils impactent le temps de chargement et d’affichage de la page. Tant que le code n’est pas chargé et exécuté la page ne s’affiche pas. Ce problème n’empêche pas de nombreuses sociétés de vendre de l’optimisation de téléchargement.

De plus beaucoup de sites deviennent inutilisables si le JavaScript est désactivé ou si il est mal interprété. Le pire étant le cas de la fonction qui ne marche pas et qui bloque des sections entières du site.

Côté développeur

le JavaScript c’est de la programmation orienté Prototype. Vous le saviez ?

Dans le web, en gros, on a deux catégories de développeurs :

• les orientés procédural (notamment les développeurs PHP, moi par exemple) ;
• les orientés objet (les développeurs Java, j’ai des notions mais sans plus).

Donc, pour tous ces braves gens, utiliser les techniques de développement habituelles pour le JavaScript c’est l’assurance d’aller dans le mur. Ou alors on fait du basique.

Un exemple tout bête, si vous écrivez plusieurs fonctions dans un même fichier et que l’une d’entre elles contient une erreur, aucune ne marche. C’est moins vrai en PHP (en Java j’ai pas tester).

De plus si deux fonctions utilisent des variables qui ont le même nom (une simple homonymie) là c’est direct, rien ne marche. Même si les variables sont déclarées séparément, JavaScript les considère comme identiques. C’est la conséquence du mélange prototypage/closure.

En gros, la deuxième fonction étend la première, de la même manière qu’en Java on peut étendre une classe en lui rajoutant des méthodes.
Il faut rappeler qu’en JavaScript tout est objet. C’est sans doute pour cela qu’il n’y a pas de mécanisme de classe (ça devrait arriver bientôt).

À l’arrivé les développeurs doivent apprendre un nouveau paradigme. À moins d’accepter d’être condamner à un code simpliste, voire brouillon.

Que faire alors ?

L’idéal serait que les sociétés réalisant des sites et des applications en ligne disposent de développeurs spécialisés. Évidemment ça coute cher, donc il est peu probable que ça arrive à court terme.

En face des SSII on a des clients qui pour la plupart n’y connaissent rien, ne s’y intéressent pas et veulent juste que ça marche (pour pas trop cher de préférence). Donc de ce côté là pas grand chose à attendre non plus.

Il faudrait juste espère que les développeurs apprennent à utiliser tous ces langages à bon escient. Et qu’ils l’expliquent à leurs patrons et à leurs clients.

Je sais, on est mal !