Frame­work js pour appli­ca­tion web


Je regarde un peu les frame­works JS pour « appli­ca­tions dans le navi­ga­teur ».

Plus j’avance plus je me dis qu’a­vec l’ap­proche mobile et la gestion du offline, on aban­donne le web tel que je le connais­sais. Même avec une foul­ti­tude de javas­cript et d’ajax, nous avons long­temps gardé l’ap­proche « vue sur le client, appli­ca­tion sur le serveur », et j’en ai été un grand défen­seur. Aujourd’­hui l’idée c’est plutôt « appli­ca­tion sur le navi­ga­teur, API sur le serveur ».

La démarche n’est pas neuve en infor­ma­tique et le milieu a déjà subit plusieurs aller-retour entre les modes « appli­ca­tion sur le client », « appli­ca­tion sur le client synchro­ni­sée avec un serveur », et « appli­ca­tion sur le serveur, vue sur le client ». Il s’agit juste d’un de ces mouve­ments mais côté appli­ca­tions web.

J’ai regardé quelques frame­works, nommé­ment Back­bo­neJS, Angu­larJS et EmberJS, plus quelques compa­ra­tifs plus éten­dus. Pour l’ins­tant j’ai l’im­pres­sion qu’ils proposent surtout une notion de MVC, avec éven­tuel­le­ment un système de rendu avec liai­son directe entre la partie modèle et la partie contrô­leur.

Je peux me leur­rer sur la complexité ou sur la valeur ajou­tée en main­te­nance mais j’ai l’im­pres­sion que ça ne sera pas mes points d’at­ten­tion. Orga­ni­ser mes classes je le ferai certai­ne­ment moins bien si je prends tout de zéro, mais ce ne sera pas ma diffi­culté prin­ci­pale. Les liai­sons directes entre vue et modèle ne me semblent pas non plus forcé­ment indis­pen­sable, ça peut même être contre­pro­duc­tif vue la perte de perfor­mance.

Par contre j’ai besoin de quelque chose pour gérer le côté appli­ca­tif :

  1. M’abs­traire des diffé­rentes solu­tions de stockage client, si possible en gérant les quotas, en ayant un méca­nisme quand on se rend compte que ce stockage a été écrasé et néces­site d’être recréé, etc. Dans l’idéal quelque chose qui ne se contente pas d’être un simple wrap­per et qui sait faire la diffé­rence entre des préfé­rences et de gros conte­nus par exemple, en me propo­sant des solu­tions diffé­rentes pour les deux cas en fonc­tion de ce qui est dispo­nible sur le navi­ga­teur (on n’uti­lise pas les API File et le local storage dans les mêmes contextes)
  2. Avoir en ligne de vue le fonc­tion­ne­ment hors ligne, avec un vrai méca­nisme de mise à jour de l’ap­pli­ca­tion, un vrai méca­nisme de mise à jour des données (synchro­ni­ser dans les deux sens, un premier méca­nisme de conflit ou de prio­ri­sa­tion en cas de conflit), des notions de « à exécu­ter plus tard une fois en ligne », etc. La ques­tion du login est aussi impor­tante (jeton tempo­raire ou perma­nent, quelle sécu­rité, etc.)
  3. Un méca­nisme complet de gestion des URL à base de popS­tate et pushS­tate de façon à ne pas avoir qu’un seul lien vers la page d’ac­cueil mais pouvoir gérer le bouton retour arrière du navi­ga­teur, les favo­ris, les liens entrants, etc. Bref, si je regarde un contenu parti­cu­lier je dois avoir une URL spéci­fique, que je peux copier, trans­mettre, utili­ser. Et par pitié oubliez les #!. C’est aussi plus diffi­cile qu’il n’y parait dès qu’on fait inter­agir ça avec le mode offline.
  4. * Une gestion de base pour les conte­nus. Si on stocke hors ligne, j’ai­me­rai avoir à jouer le moins possible moi-même avec les data:uri, et pouvoir réfé­ren­cer des images ou des conte­nus dans mes vues, à partir de choses stockées hors ligne dans un local­sto­rage, indexdb ou équi­valent
  5. C’est annexe et peut être non relié, mais si possible un jeu de widget ou templates par défaut qui s’adaptent aux diffé­rents contextes de navi­ga­tion (android, ios, win8, la manière dont on présente les listes, les menus, les retours arrière, ne sont pas les mêmes)

Vous avez quoi pour gérer ces aspects parti­cu­liers ? Parce que pour dessi­ner des pages à partir de modèles et vues OK, mais pour gérer une appli­ca­tion j’ai l’im­pres­sion d’être sans rien.

Oh, et en plus vu qu’il s’agit d’être multi-device, je ne souhaite pas quelque chose qui rame sur smart­phone. Par contre j’ac­cepte de coder beau­coup de choses à la main, je ne cherche pas forcé­ment un truc qui fasse le café. Même 4 ou 5 petites lib qui s’oc­cupent de leur partie spéci­fique, ça me va.


5 réponses à “Frame­work js pour appli­ca­tion web”

  1. 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.

  2. Merci pour ce partage de tes questions sur le sujet.

    Je suis d’accord avec Vincent que de passer une grande partie de l’intelligence du côté navigateur n’est pas si rose que ca. Les problématiques sont différentes de celles des développements classiques. Dans l’ensemble le gain n’est pas si grand que ca. D’un côté : 60/70% de développement serveur / 30/40% dans le navigateur. De l’autre on est sur du 20/80 je trouve. Le MVC permet de faire de belles applications bien structurées, mais je ne suis pas encore convaincu. Le but de mes développements est de réponde aux fonctionnalités demandées et de le faire dans les temps prévus… et pour l’instant cela prend plus de temps que de développer de façon « historique »…

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.