mercredi 9 novembre 2016

Migration vers le web : Attention, Javascript !

Les temps sont à la migration des logiciels maison vers leur version web. La volonté de plus en plus de managements d'entreprises est d'offrir leurs services sur cette plate-forme universelle et mobile. Un rapide coup d'oeil au marché leur apprend que certaines bibliothèques tiennent le haut du pavé en matière de développement front-end web (Jquery, React, Angular, Cordova, Node, …). Ils donnent donc mission au développeur de reproduire le logiciel maison, sous forme d'applicatif web, pensant qu'il s'agira simplement de traduire un langage dans un autre. C'est oublier les spécificités des développements javascript/HTML/CSS, et particulièrement sa pauvreté à tous points de vue.

Une anecdote : pendant une mission dans une grande entreprise, l'équipe dans laquelle j'intervenais, est allé se former au javascript et à Angular, car ils n'avaient jamais abordé ce monde, s'étant consacré à du développement .Net. A leur retour ils avaient des yeux grands comme des soucoupes et m'ont immédiatement interpellé en chœur : « Javascript, mais c'est quoi ce truc ? C'est n'importe quoi !». Et ils n'avaient pas tort : tout développeur de langage structuré voit javascript comme un vaste foutware, permissif, déstructuré, ce qu'il est effectivement.

Javascript : « C'est n'importe quoi ce truc ! »

Sans s'en rendre compte, les managers qui demandent de « webiser » les logiciels classiques existants, présupposent que la programmation javascript est une programmation comme les autres, mais ce n'est pas le cas. Passons donc en revue certaines des ses spécificités qui étonnent lorsqu'on ne connaît pas le développement des applicatifs web :

  • Il est lent : javascript ne tourne pas directement sur la CPU de la machine, mais sur la machine virtuelle du navigateur internet, lui-même tournant sur la CPU de la machine. Cette surcouche se traduit par une perte de performances drastiques par rapport à une application native sur l'OS. A titre d'illustration je vous propose ce simulateur de transferts spatiaux : Transfer Simulator. Vous constaterez que cet applicatif a tout d'une application native (graphisme temps réel, paramétrisation complexe, …), bref une vraie belle appli scientifique. Le problème est que si la précision de 3600s vous paraît trop faible, et que vous souhaitez une précision de 1s pour avoir des trajectoires plus précises, et bien vous pouvez attendre le résultat plus d'une heure, alors que ce serait quasi instantané sur un applicatif natif. Ce qu'il faut retenir de cela est que vous pouvez oublier javascript si vos besoin en CPU sont trop importants.
  • Il est asynchrone : javascript se comporte comme un langage séquentiel … tant que vous n'utilisez pas les événements (clics, enter, scroll, …) ni les transferts Ajax. Donc en pratique, puisque javascript est destiné à gérer des interfaces en mode SAAS (software as a service), vous travaillerez quasiment toujours en asynchrone. Quant à migrer une application séquentielle en javascript, on comprends bien qu'il ne sera plus seulement question de réécriture dans un autre langage, mais de concevoir une toute nouvelle architecture logicielle asynchrone.
  • Il possède une queue séquentielle d'événements très dure à maîtriser, rendant problématique une gestion trop riche des événements (clics, scroll, drag, animations, ...)
  • Javascript ne peut pas écrire sur le disque dur client (sauf localStorage et indexedDB, voir mon billet précédent), ni le lire, rendant impossible toute liaison directe avec une autre application de l'utilisateur.
  • Vos codes seront lisibles en clair par tous les utilisateurs qui afficheront vos pages. Il n'y a pas de possibilité de les cacher par une compilation.
  • Même si la situation s'améliore, tous les navigateurs n'implémentent pas javascript de la même façon, vous forçant à coder spécifiquement pour l'un et l'autre.
  • Javascript manipule des objets HTML, mais ces objets sont rudimentaires. Impossible par exemple d'insérer des images dans un tag <option>, ou de styler un <input type="file" />. Il faut recréer des objets plus complexes qui cacheront cette misère.
  • Les différentes bibliothèques disponibles sont le plus souvent incompatibles les unes avec les autres, mais il y en a foison, et chaque jour de nouvelles. Comment choisir la bonne ?
  • La gestion du cache des navigateurs est une épine dans le pied,
  • etc.

En fait une grande partie de la programmation javascript consiste à cacher la pauvreté du monde HTML, et à « faire croire » à l'utilisateur qu'il est devant une application « normale ». Cette illusion est possible tant que l'application n'est pas trop complexe et ne gère pas trop d'événements, mais elle possède des limites vite atteintes.

Pourtant il ne faut pas conclure que le javascript doit être délaissé, ce serait faire une autre erreur. De toute façon, vous n'avez pas le choix. Si votre objectif est d'être présent dans le monde des applicatifs web, Javascript est un passage obligé, car c'est le langage natif des navigateurs. Tant pis s'il a des défauts, il faut faire avec, car il n'y a pas autre chose. Cependant, au bout du tunnel il y a l'accès à la sphère internet, ce qui vaut bien de se coltiner javascript.

Les avantages des applicatifs web sont drastiques

Programmer javascript c'est proposer un applicatif que tous les navigateurs du monde pourront faire tourner, sur un clic, sans installation. C'est un atout crucial aujourd'hui. En outre cela vous impose de séparer clairement votre back-end et votre front-end, rendant par la même plus facile toute évolution future de l'interface (et dieu sait si les utilisateurs se lassent vite). Faisant ainsi vous structurerez vos méthodes avec les standards les plus fiables (HTML5, CSS3, Json, …), garantissant l'interopérabilité et la pérennité de vos applicatifs. Ces derniers tourneront peu ou prou en mode SAAS, vous garantissant ainsi un serveur, temps réel qui plus est, peu chargé, car tout l'effort CPU et mémoire sera assuré par l'utilisateur. Grâce à SAAS, fini le versioning, une correction sur le code et la modification est immédiatement disponible pour tous les utilisateurs.

J'arrête ici la liste des avantages, mais on pourrait la prolonger à loisir.

Réfléchir avant d'agir

J'encourage donc les managements d'entreprises à s'orienter en effet vers des applicatifs web, mais je les mets en garde sur les contraintes techniques de ce monde particulier des technologies web. Il est recommandé de ne pas les ignorer, sous peine de fiasco.

J'entends beaucoup parler d'équipes qu'on a lancé sur un développement Angular d'un logiciel maison, mais qui ne s'en sortent pas. Elles ont beau changer de Tech Lead, rien à faire, ça ne fonctionne toujours pas. C'est le symptôme typique d'une application qui est trop complexe et trop riche pour passer en Angular. Il est alors temps de se poser les bonnes questions : peut-être pourrait-elle passer en ExtJS, une des meilleures bibliothèques javascript, ou bien il pourrait suffire de repenser l'ergonomie de l'application, exploser une page complexe en 3 pages simples, angularisables. Ceci n'est qu'un exemple.

On voit par là que le développement javascript est une affaire complexe dans laquelle la technologie de développement doit être déterminée par les besoins applicatifs, eux-même jaugés par un ergonome et un graphiste. Les performances javascript étant médiocres, il est indispensable de ne développer que le nécessaire, et d'oublier les fonctionnalités superflues ou peu utilisées. Il faut donc opérer un lourd travail de factorisation des fonctionnalités, ainsi définir de façon optimale l'ergonomie fonctionnelle métier est crucial, avant de choisir les rechnologies, et de se lancer dans le développement. Ces contraintes n'existent pas pour un logiciel compilé classique, auquel on peut ajouter des fonctionnalités presque à volonté.

Quoi qu'il en soit, la technologie Javascript est techniquement à la traîne, comparée aux technologies de développement à compilation (.Net, C++, Java, …), puissantes et bien rôdées, ses fonctionnalités sont pauvres, ses performances sont médiocres. Réaliser ce que veut l'utilisateur en matière d'interface est donc souvent un challenge technique qui ne doit pas être mésestimé. C'est de plus une tâche qui désoriente totalement le développeur « classique » qui ne trouve plus ses repères habituels.

En conclusion, mon conseil avant de s'engager dans le développement d'un applicatif web, est de commencer par faire consulter le projet par un expert technique du front-end. Seul un tel expert saura indiquer les bonnes architectures, technologies et méthodes à utiliser, ce qui fera gagner beaucoup de temps et d'argent. N'oubliez pas que le monde du web et du javascript sont en perpétuel renouveau, et seul un spécialiste a les capacités de suivre ces évolutions rapides. A titre d'exemple Goole Trends vous montrera l'évolution relative de l'intérêt porté à Angular et à React, et vous verrez que ce qui était vrai il y a un an, ne l'est plus aujourd'hui. Même si un expert ne fait que valider vos vues, il sera la garantie de ne pas diriger votre projets dans une impasse technologique, car les embûches sont nombreuses.

Restant à votre disposition si vous souhaitez en savoir plus,
Cordialement
Hervé

Aucun commentaire:

Enregistrer un commentaire