JavaScript n’est pas un sous-langage

Un langage d’intégrateur

J’ai souvent remarqué que pour beaucoup de développeurs PHP, le JavaScript, au même titre que HTML ou CSS, a tendance à être considéré comme un sous-langage, “un truc d’intégrateur” qui ne mérite pas qu’on s’y attarde. Il y a donc très peu de programmeurs qui ont des compétences qui tiennent la route sur ce langage (quoi que leur CV en dise).

Cependant, je me rends aussi compte que notre métier nous confronte régulièrement à l’écriture de code JS, que ce soit pour adapter le code fait par l’intégrateur aux évolutions du projet, ou bien pour développer de nouvelles fonctionnalités non prévues dans la maquette. Lorsque l’intégrateur a terminé son travail, on ne prend en effet pas la peine de le rappeler après coup pour ces changements qui sont abordables – c’est un point qui semble admis par l’ensemble des acteurs impliqués – par un développeur backend. Il est donc aussi communément admis que la tâche ne sera qu’une formalité et sera rapidement traitée.

Malheureusement, je pense que cette idée est largement biaisée par le fait que les ajustements demandés sont le plus souvent minimes et que la qualité du code produit n’est que rarement analysée. Pourquoi cela ? Au même titre que le PHP (ou tout autre langage serveur), JS joue un rôle dans le fonctionnement de l’application, ce rôle gagnant en importance avec l’avènement des interactions côté client, ses performances tout comme sa maintenabilité sont donc essentiels à la qualité de l’application.

L’incompétence contre JavaScript

Il parait évident pour tout développeur PHP que l’application développée doit être structurée pour être maintenable et extensible ; cet aspect est aujourd’hui mis en exergue par l’utilisation quasi-systématique de la programmation orientée objet. Il ne viendrait à l’idée de personne de placer une fonction PHP dans l’espace global lorsqu’elle ne sera appelée que sur une page spécifique, ce ne serait pas “propre” (ou peut-être tout simplement parce qu’il est plus simple de charger une classe qu’une fonction grâce à l’autoload PHP, mais c’est une autre question). Pourquoi alors est-ce que dès la première ligne de JavaScript 90% des développeurs créent une fonction/variable globale ?

La vérité est que JavaScript est complexe. Tout le monde sait écrire une fonction avec des structures conditionnelles, mais les candidats sont nettement moins nombreux à se presser dès qu’il s’agit de parcourir un tableau, d’utiliser les closures ou, encore pire, d’instancier un objet.

Le syndrome jQuery

Autre conséquence de la méconnaissance du langage, l’utilisation parfois abusive des bibliothèques telles que jQuery, voire l’amalgame fait entre JS et jQuery. On m’a récemment demandé si l’opérateur new était une fonctionnalité jQuery…

Ne pas comprendre ce qu’est jQuery ni comment il fonctionne mène à des pages web pour lesquelles l’utilisation d’un profiler aurait de quoi donner des frissons. En PHP, il est normal pour la plupart des développeurs de stocker le résultat d’un traitement dans une variable pour le réutiliser ensuite. Pourtant ce genre de code JavaScript choque beaucoup moins de monde :

jQuery('#myId .child .grandchild').css(/*...*/);
jQuery('#myId .child .grandchild').animate(/*...*/);
jQuery('#myId .child .grandchild').doSomeExtraordinaryStuff();
jQuery('#myId .child .grandchild').killMeNow();

Attention tout de même, jQuery n’est pas une cause selon moi, mais simplement un résultat du problème de base : on oublie l’essentiel quand on en vient à écrire en frontend.

Quelle solution ?

Très honnêtement, je n’ai pas de solution miraculeuse. Je voudrais croire que chacun puisse s’intéresser un peu plus à tout ce qu’il écrit, que ce soit du PHP, du JS, du HTML, des scripts shell, etc. J’ai pris l’exemple de JavaScript car il est récurrent, mais on pourrait faire des remarques similaires sur toutes les technologies “annexes” à notre technologie backend de prédilection. Il me parait pourtant important de développer une rigueur dans tous les domaines que l’on touche, quelle que soit l’estime que l’on en a ou le plaisir avec lequel on s’y attarde. Ce n’est pas parce que le langage change que le contenu doit être négligé, on finit toujours par en pâtir tôt ou tard.