Je regarde un peu les frameworks JS pour « applications dans le navigateur ».
Plus j’avance plus je me dis qu’avec l’approche mobile et la gestion du offline, on abandonne le web tel que je le connaissais. Même avec une foultitude de javascript et d’ajax, nous avons longtemps gardé l’approche « vue sur le client, application sur le serveur », et j’en ai été un grand défenseur. Aujourd’hui l’idée c’est plutôt « application sur le navigateur, API sur le serveur ».
La démarche n’est pas neuve en informatique et le milieu a déjà subit plusieurs aller-retour entre les modes « application sur le client », « application sur le client synchronisée avec un serveur », et « application sur le serveur, vue sur le client ». Il s’agit juste d’un de ces mouvements mais côté applications web.
J’ai regardé quelques frameworks, nommément BackboneJS, AngularJS et EmberJS, plus quelques comparatifs plus étendus. Pour l’instant j’ai l’impression qu’ils proposent surtout une notion de MVC, avec éventuellement un système de rendu avec liaison directe entre la partie modèle et la partie contrôleur.
Je peux me leurrer sur la complexité ou sur la valeur ajoutée en maintenance mais j’ai l’impression que ça ne sera pas mes points d’attention. Organiser mes classes je le ferai certainement moins bien si je prends tout de zéro, mais ce ne sera pas ma difficulté principale. Les liaisons directes entre vue et modèle ne me semblent pas non plus forcément indispensable, ça peut même être contreproductif vue la perte de performance.
Par contre j’ai besoin de quelque chose pour gérer le côté applicatif :
- M’abstraire des différentes solutions de stockage client, si possible en gérant les quotas, en ayant un mécanisme quand on se rend compte que ce stockage a été écrasé et nécessite d’être recréé, etc. Dans l’idéal quelque chose qui ne se contente pas d’être un simple wrapper et qui sait faire la différence entre des préférences et de gros contenus par exemple, en me proposant des solutions différentes pour les deux cas en fonction de ce qui est disponible sur le navigateur (on n’utilise pas les API File et le local storage dans les mêmes contextes)
- Avoir en ligne de vue le fonctionnement hors ligne, avec un vrai mécanisme de mise à jour de l’application, un vrai mécanisme de mise à jour des données (synchroniser dans les deux sens, un premier mécanisme de conflit ou de priorisation en cas de conflit), des notions de « à exécuter plus tard une fois en ligne », etc. La question du login est aussi importante (jeton temporaire ou permanent, quelle sécurité, etc.)
- Un mécanisme complet de gestion des URL à base de popState et pushState de façon à ne pas avoir qu’un seul lien vers la page d’accueil mais pouvoir gérer le bouton retour arrière du navigateur, les favoris, les liens entrants, etc. Bref, si je regarde un contenu particulier je dois avoir une URL spécifique, que je peux copier, transmettre, utiliser. Et par pitié oubliez les #!. C’est aussi plus difficile qu’il n’y parait dès qu’on fait interagir ça avec le mode offline.
- * Une gestion de base pour les contenus. Si on stocke hors ligne, j’aimerai avoir à jouer le moins possible moi-même avec les data:uri, et pouvoir référencer des images ou des contenus dans mes vues, à partir de choses stockées hors ligne dans un localstorage, indexdb ou équivalent
- 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 navigation (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 particuliers ? Parce que pour dessiner des pages à partir de modèles et vues OK, mais pour gérer une application j’ai l’impression 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 smartphone. Par contre j’accepte de coder beaucoup 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’occupent de leur partie spécifique, ça me va.
5 réponses à “Framework js pour application web”
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.
Oui, mais pour ça il faut une connexion Internet permanente. Ce n’est pas mon cas d’usage
Quelques liens :
https://github.com/documentcloud/backbone/wiki/Extensions,-Plugins,-Resources
http://derbyjs.com/
http://brian.io/lawnchair/
http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/
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 »…
Salut,
Il y a aussi Twitter Flight :
https://github.com/twitter/flight
j’ai pas regardé en detail si ça correspond a tes besoins.