Après avoir longuement étudié les différentes architectures d’application web, j’en suis venu à la conclusion que le principe d’application full javascript n’est pas si rose.

J’étais à fond pour cette méthodologie car c’est celle qui se rapproche le plus d’une application native. Mais nous sommes en train de transformer nos navigateurs en framework de développement natif, et ce n’est pas simple et pas sans concessions, on perd notamment de nombreuses fonctionnalités qu’on considérait comme acquise depuis le développement du web.

Du point de vue des performances, les applications Javascript obligent à exécuter beaucoup de logique applicative sur le client, ce qui implique de consommer du CPU et de la RAM sur le client pour « générer » le résultat demandé (ah le DOM). Sur certains use cases, j’ai vu la version Javascript être 10 fois plus lente qu’un simple site répondant du HTML. Exit également la mise en cache du navigateur, à moins de recoder un cache local dans son application à base de localStorage.

Du point de vue du développement, les applications Javascript obligent à maintenir 2 logiques en parallèle. Bien que la logique client soit du côté Javascript, il reste une validation mineure (ou pas) des objets manipulés par le serveur, donc un double développement, le tout demandant la maîtrise de Javascript, que j’adore mais qui n’est pas évident d’accès.

Enfin, trop d’applications Javascript essaie encore d’émuler des comportements de sites web : barre de chargement, spinner, manipulation de l’historique, scroll sur fragment ID. Tout cela doit être recoder manuellement dans l’application web alors que le navigateur le fait si bien nativement.

Bref, en ce moment, je reviens à la bonne vieille application HTML, avec où il faut un peu d’AJAX pour charger du HTML de manière asynchrone (PJAX). Pas de Javascript lourd qui ralentit le client et on profite des fonctionnalités natives des navigateurs : cache, historique et surtout afficher du HTML/CSS très rapidement.