Pourquoi faut-il arrêter javascript

Javascript incontournable ? Oui effectivement, en quelques années et avec l'avènement de nodeJs, aujourd'hui le JS est devenu le language à la mode. Démocratisation des technologies du web, des navigateurs qui sont devenus de vrais petits OS en quelques années, des frameworks qui permettent de tout manipuler facilement, le JavaScript est au centre de toutes les attentions. Et c'est normal il permet de rendre dynamiques des applications complexes et tout ceci apporté au plus grand nombre d'utilisateurs via les navigateurs et les applications mobiles. Après avoir dit ça, je vous comprendrai si vous pensiez à ce moment que le titre de cet article est uniquement racoleur. Mais non, effectivement JavaScript est incontournable, mais probablement plus pour les machines de nos utilisateurs que pour nous, développeurs.

Pas adapté

On peut dire ce qu'on veut, le JavaScript est un language souple, extrêmement souple. Pas de typage de données, une gestion des erreurs un peu ambigüe... Ça peut paraître confortable dans un premier temps. Mais à l'utilisation intensive on se rend vite compte que c'est un manque, notamment lors des maintenances, des evolutions etc... Je suis partisan des contraintes raisonnables et un typage peut paraître frustrant à la déclaration d'un élément mais c'est clairement rassurant lors de son utilisation. 

L'autre point extrêmement faible (et pour lequel personnellement j'ai beaucoup de mal) c'est l'absence de gestion des objets de manière structurée. L'absence d'héritage complet est particulièrement contrariant pour les applications lourdes mais également pour la réutilisation de nos fonctionnalités. Il existe des tricks qui permettent de se rapprocher d'un héritage, mais on est plus dans le merge de fonctionnalités que dans la surcharge à proprement parler.

- Debut du coup de gueule -

De la même manière, je n'ai jamais compris la raison pour laquelle le mot clé "this" était employé de cette manière dans la gestion des évènements... honnêtement... Pourquoi cette décision? Est-ce vraiment logique de changer de contexte lors de l'exécution d'une callback d'un événement ? Effectivement il est nécessaire de récupérer l'élément déclencheur mais ce n'est clairement pas logique qu'il devienne le contexte.

- Fin du coup de gueule - .

Voilà pour les points techniques intrinsèques au language. Comme déjà évoqué, il existe des méthodes qui permettent de pallier à ces incohérences manques, mais encore une fois le language en lui même ne permet pas de faire ces choses instinctivement. On se retrouve avec des structures logiques fonctionnelles mais vite compliquées et difficilement lisible pour un travail en commun pour plusieurs développeurs qui ont leur logique propre. Pour résumer grossièrement, on pourrait dire que JavaScript est un language qui nécessite une énorme quantité de commentaires pour faciliter la lisibilité logique d'une fonctionnalité comparé à d'autres language. 

Les mauvaises pratiques

En dehors des éléments intrinsèques au language, l'une des faiblesse de JavaScript que je soulève est probablement sa plus grande force, l'accessibilité. En effet la prise en main de JavaScript est simple : pas besoin de logiciel complexe pour commencer, le premier "Hello World" se fait avec un simple fichier texte et le résultat est visible partout. Même s'il est tout à fait complet c'est un language parfait pour s'initier au code. Et c'est le problème. C'est parfait pour s'initier au code mais pas aàla logique d'un développement professionnel.

En effet, JavaScript est un language (trop) souple et la grande majorité des développeurs se sert (trop) de cette liberté. Je pense notamment aux fonctions anonymes qui y sont généralement utilisées à outrance. Il faut bien noter que les fonctions anonymes existent dans d'autres languages, ce n'est pas une spécificité de JS, mais étonnamment elles sont beaucoup plus utilisées en JS qu'ailleurs. Pourquoi ? Je ne l'explique que par l'utilisation et non pas par la logique, dans le sens où j'ai l'impression que c'est la masse des developpeurs qui au fil des utilisations a sur-exploité cette structure, construisant ainsi une forme de "bonne pratique" qui en réalité n'en est pas une. Il faut se demander quel est l'intérêt d'une fonction anonyme avant d'en utiliser une. Si le seul intérêt est d'éviter de nommer un groupe d'actions alors c'est une mauvaise raison. Le nom d'une fonction est le premier élément qui permet d'indiquer à un autre développeur ce qu'est sensé faire un bout de code. De la même manière une fonction anonyme ne peut pas être invoqué à partir d'un contexte extérieur à celui où elle a été définie. C'est là encore un problème dans notre optique de réutilisation de fonctionnalités. Cela revient à créer des méthodes privées, mais les méthodes privées ne doivent pas être la signature par défaut. Le fait d'interdire l'accès ou l'invocation à une méthode doit se justifier. Sinon vous empêcher un développeur d'utiliser une fonctionnalité dont il a potentiellement besoin, et dans ce cas il risque de se fâcher, voire pire : dupliquer du code.

Une autre mauvaise pratique est également l'utilisation à outrance des évènements. Certes la gestion événementielle est très efficace et est au cœur du language, je pourrais en faire l'éloge par rapport à une notion de hook par exemple, mais dans les applications avec un grand nombre de fonctionnalités, on a tendance à multiplier les évènements. Difficile de s'y retrouver quand un évènement est écouté par des dizaines d'éléments. Sur de grosses applications il est parfois préférable de limiter les écouteurs, de créer des modèles qui vont gérer des "états" de l'application. Un événement déclanchera une modification d'état. Il sera ainsi plus simple de traiter les modifications de contrôleurs, de vue, ou de données en fonction d'un état de l'application plutôt qu'une multitude d'événements croisés. À noter qu'avec les frameworks modernes comme angulaire, react ou vuejs, cette notion d'état commence à être populaire.

Alors pourquoi coder en JavaScript ?

Heureusement tout n'est pas perdu pour le JavaScript. En introduction, je faisais allusion à ses utilisations et ses performances et ce n'est pas pour rien qu'aujourd'hui JavaScript est aussi répandu. Il faut considérer ce language comme un language compilé interprété par les navigateurs. Même si dans les faits ce n'est pas du tout le cas, dans l'utilisation on se rapproche déjà de cette logique. En effet, vous avez beau coder en JS pur, vous ne balancer pas directement vos sources aux navigateurs, vous les minifiez, vous les transformez pour les rendre performantes. Donc en quelque sorte vous compilez déjà votre code source. Alors pourquoi continuer à coder en JS avec tous les défauts qu'on a évoqués ? En milieu professionnel notamment, ça revient à utiliser une technologie qui nous fait perdre du temps en conception, évolution, réutilisation et maintenance. Code-t-on encore en assembleur ? Non, on utilise des languages facilitant le développement et on utilise des compilateurs pour rendre le code interprétable. Aujourd'hui on peut faire la même chose avec des language tels que TypeScript ou CoffeeScript, qui compilent en Javascript. Ils proposent des fonctionnalités plus proche des autres languages industriels et permettent donc de pallier aux problèmes intrinsèques de JS (du moins en partie, mais c'est un bon début). Il ne reste plus au développeurs qu'à apprendre de bonnes pratiques.

Conclusion

En conclusion il ne s'agit pas d'abandonner JavaScript, celui-ci est incontournable, pour le moment. Il est en revanche nécessaire de prendre du recul afin de voir ce qui peut nous empêcher d'avoir des développements efficaces. Et le language Javascript de base est un problème pour les développeurs. En effet, on apprend toujours et on code toujours dans un language, certes facile à prendre en main, mais truffé d'incohérences et de manques en ce qui concerne des besoins de réutilisation et de maintenance. Ajoutez à ça des mauvaises pratiques qui se sont installées au fil du temps, vous obtenez un language qui n'est pas forcément adapté aux besoins de developpeurs professionnels alors qu'il est pourtant parfait pour les utilisateurs d'application. Dans ce cas, il est nécessaire de se poser la question de l'utilisation d'une surcouche adéquate pour les développements avec un language qui compilerait en Javascript. Avec ce système déjà répandu avec l'utilisation de TypeScript ou autre, on satisfait et l'utilisateur et le producteur et le client.