Le client riche : Quelles technologies ont un avenir ? [Débat]

[yphilogene]

Bonjour à tous,

J'aimerais amorcer un échange autour d'un sujet à la mode et dans le fond très intéressant: le client riche.

Le "client riche" se définit le mieux à travers l'objectif qu'il vise: offrir à une application l'ergonomie du "client lourd" tout en conservant la facilité de déploiement/maintenance du "client léger".

Des langages comme le PHP, l'ASP et le JSP permettent de générer des pages HTML et ainsi de construire des "applications web" exploitable côté client à travers un interpréteur HTML, autrement dit un navigateur basique. Ceci constitue pour moi le modèle "client léger". Le HTML est le seul language compris côté client.

Le langage Javascript vient alors s'intégrer au navigateur (le client léger devient donc légèrement plus riche), lui permettant de faire autre chose que de restituer le code HTML envoyé par le serveur. Sa combinaison avec le formalisme XML aboutit à l'AJAX qui a permis de voir naître des applications web légèrement plus ergonomiques avec du drag&drop par exemple comme nouvelle fonctionnalité. Là encore, le navigateur est suffisant. Mais il s'agit d'un navigateur enrichi. On peut encore y ajouter le Flash Player ou la Java Virtual Machine et on obtient un client pas si léger que ça.

Pour aller plus loin, il faut avoir un langage de script plus riche que le Javascript couplé avec un langage de description d'interface graphique plus complet que le HTML voir extensible. Adobe par exemple propose Flex qui couple ActionScript et MXML. Microsoft propose Silverlight qui interprète du XAML mais le language de script reste le Javascript. Mozilla intègre lui XUL directement dans le navigateur Firefox et la suite applicative SeaMonkey, mais là encore le langage de script reste Javascript.

Toutes ces nouvelles solutions restent à l'intérieur du navigateur mais tend à s'en désolidariser. Adobe Integrated Runtime (AIR) est une machine virtuelle permettant de faire fonctionner des clients riches en dehors du navigateur, mais tout en utilisant ActionScript et MXML. Mozilla proposera bientôt XULRunner, machine virtuelle permettant d'interpréter XUL en dehors de Firefox ou SeaMonkey qui à termes devrait elles mêmes être des applications tournant sur XULRunner.

Il s'agit là de modèles de développements d'applications web riche, c'est-à-dire ne pouvant plus s'exécuter sur un navigateur basique. La discussion que j'essaye d'amorcer tenterait de déterminer objectivement quel est le modèle le plus complet.

Au fil de mes lectures, il m'apparait que le modèle proposé par Sun et résumé sous le nom JavaFX est le plus prometteur. Avec J2EE, la technologie Java est bien éprouvée en termes de "client léger". Avec JavaFX, Sun vise à compléter sa Java Virtual Machine pour enrichir le client.

En ce qui concerne le développement, le code du langage JavaFX script est limpide et est appuyé par la Javadoc. Des plug-ins sont proposés pour les IDE Netbeans et Eclipse, et Sun offrira bientôt un outil non encore nommé destiné aux designers d'interfaces graphiques.

Le couple J2EE/JavaFX me semble répondre de façon complète à l'objectif du client riche (cf. plus haut).

Qu'en pensez-vous?

[Médinoc]

Pour moi, dès que ça dépasse le niveau "Javascript" (exemple: du Flash ou une applet Java), c'est déjà un client lourd.

[yphilogene]

Je serais tenté d'être encore plus extrême en affirmant que dès que Javascript est utilisé, ce n'est plus du client léger. Par exemple, GMail propose une version "basic HTML" afin de fonctionner sur le plus basique des navigateurs. Je suis donc tout à fait d'accord avec toi sur ce point.

Pour qu'il y ait enrichissement du "client léger", il faut qu'il y ait des moteurs supplémentaires installés côté client, par exemple Silverlight de Microsoft qui est un plug-in à installer sur le navigateur ou XulRunner qui est une machine virtuelle à installer sur l'O.S. Les futurs versions du navigateur Firefox seront construites sur XULRunner, donc j'imagine que l'intégration de cette machine dans ce navigateur sera implicite (pas de plug-in à installer).

Pensez-vous qu'il soit nécessaire qu'un navigateur intègre de base l'ensemble des différents moteurs existants à ce jour, sans qu'il y ait d'installation de plug-in à effectuer? Cela impliquerait la présence de tous les moteurs sur le client, ce qui me semble assez lourd (c'est le mot...).

Je crois qu'une entreprise, avant de développer son application web riche, sera contraint de choisir un des moteurs côté client et son pendant côté serveur, et c'est bien pour cela que je me demande quelle est la technologie qui vous semble la plus complète dans le domaine bourgeonnant des application web riches.

Avez-vous déjà développé une application web riche reposant sur Abode AIR par exemple?

[_Mac_]

Pour ce qui est du client web qui intègre tous les moteurs, ça n'a aucun : comment tu fais pour intégrer un nouveau moteur ou une nouvelle version de moteur ? Sans parler du fait que les éditeurs vont refuser d'intégrer les moteurs des concurrents (tu devines à qui je fais allusion).

Pour info, Eclipse propose une version "moteur seul" de l'IDE qui permet justement de développer ses propres applications, par exemple des applications utilisant massivement les Web services, ce qui fait de lui aussi un candidat au client riche, quelque part.

Par goût, j'aurais une tendance pour JavaFX, mais l'inconvénient majeur de la solution reste le déploiement sur le poste client : il faut quand même installer un programme pour que ça fonctionne, donc c'est pas top de ce côté-là. Et a mon sens, c'est bien tout le problème.

En ce qui concerne les fonctionnalités, je pense que tout le monde est conscient des limitations du modèle actuel HTML + JavaScript (+ Ajax, pour faire tendance). Tous les nouveaux frameworks de client riche qui apparaissent intègrent des fonctionnalités avancées, qu'on peut pratiquement retrouver d'un moteur à l'autre, qu'on ne peut pas retrouver avec un navigateur standard.

Je résumerais donc la problématique par rapport à cette question : quel est le modèle de déploiement des clients riches ? 2 solutions s'offrent à nous :
- Si une entreprise ne veut rien installer sur les postes client, on est obligé de passer par un client léger (navigateur Web standardisé dans l'entreprise) qui fera de l'Ajax, dans les limites de ce dernier, ou qui installera éventuellement des plug-ins genre ActiveX, mais qui utilisera du coup certainement des technologies propriétaires.
- Si une entreprise accepte d'installer un programme sur le poste client, là tu as effectivement le choix entre les différents éditeurs. Pourvu 2 choses : que la solution de l'éditeur propose un déploiement "centralisé" de l'application (i.e. l'application ne réside pas directement sur le poste client, seulement le moteur), et que la mise à jour du moteur installé sur le PC soit possible et de manière la plus automatisée et transparente possible.

Mais sinon, j'aime bien Java, j'en fait depuis des années. Les applets, c'est plutôt pas mal, même si c'est assez boudé, et Java Web Start, c'est excellent aussi, mais ça prend pas. Pour moi, c'est le modèle de déploiement le plus intéressant (et qui à son époque, avait bien de l'avance sur ses concurrents). Je pense que Sun veut donner un coup de boost à cette solution avec JavaFX.

[yphilogene]

Exactement. L'entreprise a bien le choix entre 2 stratégies:

1 - Aucune installation côté client (en dehors du navigateur qui est fourni le plus souvent avec l'O.S.): stratégie client léger.

2 - Installation côté client: stratégie client riche.

J'ai évoqué un navigateur qui serait capable de faire fonctionner tous les moteurs en pensant qu'une entreprise pourrait le choisir comme navigateur standard qu'il incluerait dans le package d'installation de tous ses postes clients. Mais cette idée est assez farfelue, se situe un peu au milieu des 2 stratégies, et un tel navigateur serait finalement une sorte d'IDE (sans les possibilités de programmation) comme Eclipse effectivement.

Mettons de côté cette idée pour nous concentrer sur la stratégie n°2: déployer et faire évoluer un client riche sur tous les postes de travail.

Je trouve ton idée de "déploiment centralisé" (uniquement le moteur installé sur le poste client, pas l'application) très intéressante parce qu'elle permet de réaliser la mise à jour de l'application uniquement sur le serveur (gain de temps, gain d'argent). Mais techniquement, je ne suis pas sûr de savoir comment cela fonctionne. Imaginons que le poste client dispose simplement d'un lanceur pour démarrer l'application. Ce lanceur se charge d'établir la connexion avec le serveur pour amener l'application du serveur vers le client. A sa fermeture, l'application se décharge du poste client. Est-ce bien cela que "Java Web Start" et Applets permettent de faire depuis des lustres?!

Voilà pourquoi je suis plus attiré par JavaFX que par les autres solutions de client riche. J'ai l'impression que tout est déjà là: un moteur qui se met à jour automatiquement (la Java Virtual Machine) et le lanceur (Java Web Start). Tu as raison, en termes de déploiement et mise à jour d'une application, c'est particulièrement élégant et adhère parfaitement à la philosophie des applications web! Donc JavaFX viendrait enrichir le moteur de nouvelles fonctionnalités "orientées client riche" afin que le développeur (ou même le designer) puisse créer plus rapidement une application web riche.

Mais pourquoi JavaFX n'arrivera qu'au second trimestre 2008? Rajouter des fonctionnalités "orientées client riche" à un moteur déjà existant ne m'apparait pas comme une tâche particulièrement difficile pour des informaticiens aussi talentueux. Je pense (ou plutôt j'espère) que Sun profite de l'occasion pour améliorer son moteur sur d'autres aspects pour donner un vrai coup de boost comme tu dis à la solution Java côté client.

_Mac_, toi qui travailles avec Java côté client depuis des années, quels sont selon toi les défauts qui l'handicapent aujourd'hui et comment JavaFX (je parle de cette sorte d'upgrade dont va profiter la JVM, pas simplement du langage JavaFX script) pourrait rectifier le tir?

[_Mac_]

Oui, Java Web Start est une sorte de lanceur d'application distantes : il télécharge l'application au besoin.

Pour JavaFX, je ne sais plus trop pourquoi Sun met du temps à le sortir. J'ai lu un papier sur lemondeinformatique.fr je crois, du gourou Java chez Sun et qui expliquait les enjeux de JavaFX. Malheureusement, je ne saurais trop t'expliquer les tenants et les aboutissants. Sinon, on a dû mal se comprendre : je travaille surtout côté serveur

Pour ce qui est de la stratégie n°1, je ne l'excluerais pas totalement pour 3 raisons :
- Les évolutions des techno Web. Certes, c'est (très) lent à se mettre en place mais le W3C travaille sur des versions plus évoluées de HTML. On peut s'attendre à des enrichissements conséquents sur les prochaines versions avec, pourquoi pas, des fonctionnalités avancées permettant le développement d'IHM évoluées faciles à mettre en oeuvre et sans la lourdeur d'Ajax.
- Les fonctionnalités propriétaires : de ce que j'ai compris, Microsoft surtout, un peu moins Mozilla, travaillent justement sur des versions "maison" de langages de type XML pour le développement d'applications riches fonctionnant dans le navigateur. C'est un peu batard, on ne sait pas trop dire si c'est de la stratégie 1 ou 2, mais ça a l'avantage de ne nécessité qu'un navigateur. L'idée, je pense, c'est qu'à un moment donné, le W3C intègre ce genre de technologies pour normaliser un langage standard de développement d'applications riches.
- EDIT : j'ai oublié la 3ème raison

EDIT : c'est pas lemondeinformatique.fr, mais 01net : http://www.01net.com/editorial/36321...-aujourd-hui-/

[yphilogene]

Pas de méprise, j'ai bien compris que tu travaillais côté serveur .

J'avais également lu l'interview de James Gosling sur 01net (il y avait effectivement eu un podcast d'une interview précédente sur lemondeinformatique.com à l'occasion du Sun Tech Days en mars) et c'est elle qui a réellement éveillée mon intérêt pour JavaFX. En mars, je ne voyais ça que comme un langage de script supplémentaire, mais il s'agit en fait d'un upgrade significatif de la JVM.

Je n'exclus pas non plus la stratégie 1 et je pense aussi qu'un jour peut-être le W3C finalisera un nouveau langage qui simplefiera la syntaxe et offrira des nouvelles possibilités dans la description d'une interface graphique.

Cela pour moi rejoint l'objectif des langages de description comme XUL de Mozilla, XAML de Microsoft ou encore MXML d'Adobe. Offrir un moyen de décrire de façon plus complète et plus souple une interface graphique (je pense notamment au XBL chez Mozilla qui permet de créer ses propres éléments d'interface pour étendre ce que propose XUL de base).

Mais cela reste de la description, non? Cela ne permettra pas par exemple d'interagir avec l'environnement du poste client. Je m'amusais tout à l'heure à charger quelques photos sur Facebook en utilisant Firefox. Pour uploader des photos, l'application web intégrée dans Facebook doit avoir accès à l'arborescence des fichiers de mon poste de travail, et là, c'est la JVM qui se met en route...

Comment un langage de description, aussi riche et souple soit-il pourra permettre à un navigateur d'interagir avec l'environnement client? A moins qu'en plus de ce langage, le W3C définisse un moteur standard à intégrer dans le navigateur.

Franchement, quelles différences y a-t-il entre:
- upgrader le navigateur de tous les postes clients pour passer au super navigateur homologué W3C,
- installer sur tous les postes clients le moteur et lanceur nécessaires pour faire fonctionner une application web riche?

Pour moi, les deux solutions se rejoignent. L'amélioration du navigateur nous fait déjà quitter la stratégie 1 pour la stratégie 2. Sur ce sujet, je me suis déjà fait mon avis: dans le cadre d'une entreprise, le navigateur doit rester basique et ne doit pas permettre d'interagir avec l'environnement client, ne serait-ce que pour des raisons de sécurité.

A côté de cela, le couple moteur/lanceur pour accueillir les applications web riches de l'entreprise. C'est tellement plus propre ainsi!



Maintenant, je me pose la question suivante. On parle de plus en plus de travail en mode déconnecté, permettant à l'utilisateur de manipuler l'application web riche lorsqu'il n'a pas accès au réseau de l'entreprise. Prenons l'exemple d'une application comme Google Docs et supposons que l'utilisateur veuille travailler son spreadsheet Google sans être connecté à Internet. Pour moi, il n'y a pas d'autre choix que de faire une copie du fichier sur le poste client qu'il faudra ensuite synchroniser avec le fichier du même nom sur le serveur. Des logiciels de messagerie comme Lotus Notes mettent en oeuvre des mécanismes de synchronisation des mails. J'ai aussi eu l'occasion de travailler avec l'application Siebel CRM gérant des portefeuilles clientèle. Cette application propose un mode "offline" avec mécanisme de synchronisation de son portefeuille clientèle.

Ca ne me semble pas être un truc très simple à implémenter. Est-ce que quelqu'un l'a déjà expérimenté avec Adobe AIR ou Java?

[eracius]

Envoyé par yphilogene

On parle de plus en plus de travail en mode déconnecté

C'est marrant j'avais personnellement l'impression que l'idée d'un logiciel fonctionnant en offline était complètement HasBeen ...
Sous l'impulsion de google qui justement nous propose un environnement en ligne toujours plus riche, êtes vous vraiment sûr que le mode déconnecté représente vraiment encore un quelconque intérêt ?

[CAML]

Sinon y a les 'XBAP' du coté de microsoft qui permet de faire tourner une applic en tant que .exe ou bien la lancé via un navigateur (IE ou bien Firefox et quelques consort).

[erca57]

Envoyé par eracius

offline [...] complètement HasBeen ...
êtes vous vraiment sûr que le mode déconnecté représente vraiment encore un quelconque intérêt ?

Les logiciels fonctionnant en mode déconnecté restent indispensables pour les pc nomades par exemple, dont le nombre ne cesse de croître.

[arfany]

Envoyé par erca57

Les logiciels fonctionnant en mode déconnecté restent indispensables pour les pc nomades par exemple, dont le nombre ne cesse de croître.

Les points Wifi aussi

[fr1man]

La théorie du client léger qui ne nécessite aucune installation ne m'a jamais convaincu. En effet, deux navigateurs différents (IE, Firefox) ne réagissent pas toujours de la manière face au même code, mais c'est le cas aussi pour deux navigateurs identiques dans des version différentes (IE 6, IE5.5), donc au final on est très loin du code html soit disant interprétable par n'importe quel navigateur.
Si à cela, on rajoute javascript, le problème s'accentue encore.

Du coup, je trouve que des solutions comme Java WebStart, même si elles ne sont pas parfaites, sont trop souvent négligées. La mise à jour de l'application se fait automatiquement par téléchargement sur le serveur.
Ok, on peut être amené à mettre à jour la JVM sur le poste client si l'application doit utiliser de nouvelle fonctionnalités propres à une JVM plus récente.

Au final, je dirais que selon les besoins, on peut choisir l'un ou l'autre et qu'il n'y pas de solution meilleure que l'autre.

[MoscoBlade]

Envoyé par yphilogene

Microsoft propose Silverlight qui interprète du XAML mais le language de script reste le Javascript.

pour la version 1.0 d'accord, mais pour la v 1.1 Silverlight couple XAML et C# avec un framework allégé.

Mosco

[jeromek]

coucou à tous,

Moi perso j'utilise PHP et javascript, pour l'interface riche, la bibliotheque YUI (Yahoo User Interface) qui a encore quelques bugs mais qui dans l'ensemble est très correcte. Donc cette solution evite de devoir mettre en place une startegie de mise à jour des moteurs xyz coté client.

Pour les solutions adobe, microsoft et autre, je pense que le match sera remporté par celui qui sera le plus innovant et qui appliquera la meilleur strategie marketing.

[Traroth2]

Envoyé par eracius

C'est marrant j'avais personnellement l'impression que l'idée d'un logiciel fonctionnant en offline était complètement HasBeen ...
Sous l'impulsion de google qui justement nous propose un environnement en ligne toujours plus riche, êtes vous vraiment sûr que le mode déconnecté représente vraiment encore un quelconque intérêt ?

L'enjeu, c'est de faire des applications qui vont pouvoir fonctionner en ligne ET hors ligne. Un exemple : On pourrait facilement imaginer un traitement de texte qui fonctionnerait en ligne, comme Google Documents, mais qu'on pourrait aussi utiliser hors ligne. L'application sauvegarderait alors le travail en local et se synchroniserait toute seule avec le serveur dès que le réseau serait à nouveau disponible.

En dehors de ça, c'est sûr, JavaFX, et plus généralement les nouvelles évolutions de Java 7, c'est prometteur. Mais ce qui est annoncé pour l'instant est trop incomplet : JavaFX Script permettra la réalisation d'interface graphique et Java 7 intégrera le système de librairies modulaires permettant de démarrer une application et en particulier une applet beaucoup plus vite. Mais il manque encore plein de fonctionnalités pour rivaliser efficacement avec Flash : gestion du multimedia, et notamment du streaming, video et audio (Cortado, c'est trop limité), affichage vectoriel (même s'il semblerait que des choses soient prévues dans ce domaine avec JavaFX. Il y a deja un convertisseur SVG-JavaFX qui existe, je crois), moteur de rendu HTML (il y a un projet appellé Flying Saucer sur java.net, mais je ne sais pas s'il est prévu de l'intégrer à JavaFX)

[theMonz31]

Bonjour

A titre professionnel, je développe depuis presque 10 ans que des applications
"déconnecté"...

Et pour la question n'est pas de savoir, client Leger / client lourd mais plutot de savoir si on developpe des applications qui s'execute sur une machine avec eventuellement connection (si dispo) sur le net, ou si on developpe des applications hébergés dans un browser et qui donc sont "pour l'instant" assez lié au fait que la connection internet, intranet, etc.. (bref du reseau) est disponible...

Au vue des dev que l'on fait dans ma société (Cap gemini Sud ouest), j'aurais
tendance à dire que la tendance, justement, est au "massivement" web

Et j'aime autant vous dire que je suis très triste de cela ...

Personnellement, je trouve qu'il est bcp plus facile d'avoir une application
stand-alone performante, chatoyante, rapide avec les fonctionnalités qu'on aime (undo /redo, copy paste, drag & drop (depuis OU on veut) que lorsque j'ai pu approcher des dev en asp.Net

Apres, souvent, on me sort comme argument : LE DEPLOIEMENT

JE suis d'accord que deployer une application (.Net pour mon cas en étant expert) est , pour une grande partie de nos clients (grands comptes) une
problématique forte.. En effet, ces clients sont "fatigués" d'avoir à installer
sur 10000 Postes des mises à jour word, etc... (bon, maintenant, ce se fait automatiquement quand la machine se connecte et non plus le serveur qui cherche les machines pour les mettre à jour)...

Avec le web, on simplifie grandement ces aspects

Cela dit, avec le deploiement Click Once (un exemple sympa étant Paint.Net), on peut tout à fait se retrouver dans des modes d'utilisation assez proche
de ceux du web... avec l'avantage de pouvoir exploiter son logiciel meme si on est completement Hors Reseau

Parce que pour moi, d'un point de vue stratégie et sécurité, plus il y a de reseau, et plus il y a de risque de blocage...

Le jour ou tout le reseau est par terre, si on a un Word via Web => nické
Et identique pour le reste

Et de plus, plein d'application n'ont pas besoin d'etre "distribué" et par ailleurs requiert des performances de traitement que l'on n'a pas encore atteint coté web (quelque soit le client)

En clair, je comprends l'attrait du web , mais pour moi, si le developpement d'application "stand alone" ou pouvant etre deconnecté se marginalise, je pense qu'on aura fait une grosse regression dans le monde de l'informatique

The Monz, Toulouse

[nicorama]

Envoyé par Médinoc

Pour moi, dès que ça dépasse le niveau "Javascript" (exemple: du Flash ou une applet Java), c'est déjà un client lourd.

Pour moi le principal soucis dans l'"expérience utilisateur" , c'est le temps de latence quand il fait appel à un client riche en flash ou plus encore pour une applet Java.
Faut dire que le lancement de la machine virtuel, et les bugs qu'il occasionne sur Firefox quand l'applet est mal détruite sont assez casse-pied.

Comme souvent, Sun est à deux doigts de la solution -améliorer le lancement après avoir considérablement améliorer les performances - et va se perdre dans une sémantique marketing incompréhensible, avec sans doute d'excellentes solutions techniques.

[lunatix]

essaye la JRE qui arrive (update 6) voir le blog de la section java pour le lien. démarrage instantané de la jvm

[rattlehead]

Bonjour theMonz31
tu pourrais dire en quoi ce serait une régression si on abandonnait les logiciels en stand ou déconnectés?

[Traroth2]

Sinon, dans le projet sur lequel je travaille (en ligne sur kizoa.fr), on utilise Flex et bientôt Air. Bon, je m'occupe de la partie serveur, en Java, donc mon expérience de Flex est limitée.
Ca a le mérite d'être mûr, contrairement à Silverlight ou JavaFX, mais je trouve ça peu performant (et c'est un euphémisme) et franchement gourmand, tant en mémoire qu'en CPU. Quand on a testé la première fois l'application sur MacOS X/Safari, ça faisait peur tellement c'était lent...
Sans parler des problèmes de compatibilité entre les versions de Flash : le plug-in Linux pour Flash 9 marche vraiment très mal (impossible de faire tourner notre appli Flex dessus, par exemple) et Flash 9 embarque 2 runtimes d'execution Actionscript distincts, pour AS2 et AS3. C'est un peu bancal, comme manière de fonctionner, je trouve. J'ai peur qu'Adobe ne prenne plein les dents quand Microsoft et Sun débarqueront vraiment sur le marché...